The migration from HELM to WebsitePanel is now complete, and all cfdeveloper accounts on the old HELM systems have been deleted along with all data on the servers, and the servers have now been switched off and are no longer accessible, so there is no longer any possibility of recovering any of the data that was on those servers.
I did keep the servers online for an addiitonal month after cut off date (30th March) to allow for anyone that managed to completely miss the newsletter last september, and has not been reading the blog and thus missed all the updates posted since then.
During April all sites were down allowing any remaining users time to contact me and get temporarily switched back on for migration. of which there were very few thankfully.
This gave a total of 7 months for migration, so if you did not manage to migrate your sites during that time then i'm afraid it is too late as they have now gone forever, this includes databases, data sources, everything.

Any users from the old HELM system should now simply signup again as a new user.

The issues with Enabling ColdFusion inside WebsitePanel are now also fixed, it should now be fully working and my changes/fixes have been rolled out in the latest WebsitePanel 1.2.1 release.

You will however need to undo any of the previous manual fixes in order to enable ColdFusion via WebsitePanel, otherwise they will clash, there should be no Coldfusion related handler entries in your web.config.
The only handlers you should need to enable in your web.config are the Railo ones, although this will also be done by WSP in a future update as well.

Hi Folks, this is just a final reminder that the 6 months migration period is now almost up and the old HELM servers are being retired at the end of this month. Once the servers are switched off you will no longer have any access to your site or files and your HELM account will no longer be accessible.

So if you have not yet migrated your sites to the new system then you need to do it now.
To remind you, here is the link to last Septembers newsletter which contains the migration instructions.

Further to my previous post about the problems with the Coldfusion enablement in WebsitePanel, I have now found a better solution until this is fixed, therefore if you did follow those instructions already you may now be getting an "internal server error", if so then then please click the below screenshot for the solution.

ColdFusion is now simply enabled on all sites by default, so you do not need to enable it via WebsitePanel any longer or apply the aforementioned fix, you only need to enable the virtual directories on the ColdFusion tab.

If you use Railo then there is a very slight change to the Railo instructions HERE, the change simply disables the ColdFusion handler to make sure you are using railo and not ColdFusionm this is done simply by adding the following to the handlers section.

<remove name="coldfusion" />

If you are an exisitng Railo user then you may posisbly find that your site is now using ColdFusion instead, in which case simply apply the above change in your web.config.

Please ignore the below instructions, a new solution has been implemented which can be found HERE.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hey folks, if you are using the developer hosting then you may find that ColdFusion is no longer working on your site, this is because I had to make some changes to fix a bug with the coldfusion connector. this does not affect Railo.

Unfortunately this has had an adverse side effect and now when WebsitePanel enables ColdFusion it doesn't work.

Until I have fixed this the current work around is to manually enable ColdFusion. To do this simply edit the web.config file in your website root (wwwroot) and add the following in the <handlers> section, I suggest you backup the file first just in case as this can break your site.

<remove name="ColdFusion (*)" />
<add name="ColdFusion (*)" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\ColdFusion9\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll" resourceType="Unspecified" requireAccess="None" />

In addition you may also need to check that you have index.cfm set as a default document.

so your entire web.config should look something like this, unless you have customised it.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>

 <directoryBrowse enabled="false" />

 <defaultDocument>
 <files>
 <clear />
 <add value="Default.htm" />
 <add value="Default.asp" />
 <add value="index.htm" />
 <add value="index.html" />
 <add value="iisstart.htm" />
 <add value="default.aspx" />
 <add value="index.cfm" />
 </files>
 </defaultDocument>
 <handlers>
 <remove name="ColdFusion (*)" />
 <add name="ColdFusion (*)" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\ColdFusion9\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll" resourceType="Unspecified" requireAccess="None" />
 </handlers>

</system.webServer>
</configuration>

If you have been having performance problems with CFBuilder or CFEclipse on windows (slowness, high CPU usage) then you may find the following solution provided by Kevin Miller useful to help resolve your issues.

For those of you that continue to experience hangs and massive slowdowns running CFB on Windows 7 64bit, the one thing I found that made all the difference in the world is to have Eclipse use the jvm.dll rather than javaw.exe (the default).  I’m using the CFB plugin into Eclipse, but I suspect this may also apply to CFB standalone on Win7 64bit as well.  No amount of configuration changes, switching between 32 and 64bit JVM/Eclipse or disabling of features made any difference to the significant performance problems I was continuing to experience UNTIL I explicitly had Eclipse start up using the dll (forcing the JVM to load within the Eclipse process).

I also found that simply adding the –vm argument to the eclipse.ini apparently doesn’t work when trying to specify a specific JRE to use (at least on my machine); regardless of the existence of this argument in the ini file, it will still always fire up C:\Windows\System32\javaw.exe, which is where the problems I was seeing are (high CPU utilization, memory consumption).  Not sure why that argument is ignored, perhaps a path issue, but I found that the only way I could be certain that I could run Eclipse with a specific JRE was to invoke Eclipse with the –vm command line argument.

I removed all my old JRE installs and installed the most recent 64bit JRE to C:\Java\64bit\.

What didn’t work:

I first tried updating eclipse.ini with:

-vm C:\Java\64bit\jre6\bin\javaw.exe

but found that Eclipse was still invoking the C:\Windows\System32\javaw.exe for some reason.  Eclipse started of course, and the javaw.exe process started going bananas again every time I would try to edit a file and *change the value of an html input tag* of all things – as soon as I changed the input value by adding one letter (even before saving) the javaw.exe process would immediately start eating cpu and memory, and I could repeat this problem consistently across multiple files.  Eclipse would hang, and I’d have to forcibly kill it as it would never recover.

I then tried invoking Eclipse with the command line –vm argument, like so:

D:\eclipse\eclipse.exe -vm C:\Java\64bit\jre6\bin\javaw.exe

leaving all the other arguments alone in the ini file; now, I could see that it was definitely using this particular javaw.exe but had exactly the same behavior I described above, edit a file (local filesystem, not network just to clear that it isn’t network related) and javaw.exe freaked out and Eclipse hung until forcibly killed.

I then tried changing the –vm argument in the eclipse.ini file to:

-vm C:\Java\64bit\jre6\bin\server\jvm.dll 

When Eclipse started it still had fired up javaw.exe in the Windows system32 directory as above.  Whatever.

What worked:

Finally, I invoked Eclipse using the command line –vm argument pointing to the JRE’s jvm.dll, like so:

D:\eclipse\eclipse.exe -vm C:\Java\64bit\jre6\bin\server\jvm.dll  

and holy crap, it runs great.  Responsive, no appreciable sluggishness, I even turned a bunch of the code assist and insight features back on in light of how great it works now.  Because javaw.exe isn’t running I have seen none of the problems I had when using the default invocation.  I don’t understand why this option isn’t talked about more (I recall seeing only one reference to it in all the stuff I read), nor why it works better for me than the default javaw.exe but I’ve been running it all day now and it has been working terrific so far.

So, if you’re on Win7 (or maybe even Vista) 64bit, have a 64bit JVM and 64Bit Eclipse and are seeing crappy performance or stability, try this method and see if it doesn’t solve your problems.  Off now to uninstall IntelliJ and Komodo trials ….

Trackback url