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

Some folks seem to having issues getting their head around this subject, so I thought I would do a quick post to explain it further.

Data Source Names

A DSN (Data Source Name) is required to connect your application to your database.

In HELM there was an option to setup a ColdFusion DSN, this doesn't exist in WebsitePanel, so you need to request Data Sources to be setup manually. NOTE: ODBC DSN's do not work with Coldfusion.
This is not required for RAILO, if you are using Railo then simply login to your Railo web admin to setup Data Sources.

RDS Access

RDS allows you to connect to your databases and use debugging tools directly from dreamweaver or CFbuilder. Again there is no way to do this automatically, you need to request RDS access to be setup for you. You only need to do this once though. Please refer to the ColdFusion documentation for mor einfo on RDS.
This also involves setitng up a security sandbox so that you cannot RDS into other users sites and databases, so once you start using RDS then you will also need to get any news sites or DSN's you setup added to your sandbox before you will be able to use RDS with them.

This applies only to Coldfusion, Railo does not have RDS.

To simplify this process I have created a new DSN/RDS Support form when you can submit your requests.

Go Here: http://www.cfmldeveloper.com/page.cfm/support/rds-dsn-support

This is only a temporary requirement as I am currently working on an application to allow users to manage their own DSN's, RDS users  and Sandboxes.

The next version of ColdFusion (10) is codenamed Zeus. Although it is still in development and most of the secrets are still under wraps, some sneak peaks were released at the recent RIACON.

Solr. In CF10 say goodbye to Verity and document limits. Solr is now the only search engine in CF10. It does basic searches with the tags, but if you dig into the power of SOLR using Java you can do much more.

Web Services are better than ever. Now they support Apache Axis2, which includes full REST support. Sorry SOAP, you are no longer the only service in town. And don’t forget, WSDL 2.0. But unlike a Java implementation of Axis, the engineers got Axis and Axis2 to run side by side – which means full backward compatibility.

Apache Tomcat is perhaps the most popular and anticipated change coming to CF 10. Adobe’s antiquated Java engine JRun is finally being put to rest. JRun never really became that popular, whereas Tomcat is the most popular servlet engine and has wide support in the Java community. And Adobe will be giving Tomcat it’s full support. Just putting a more robust, yet lightweight Java server in the mix will result in significant speed and reliability improvements. The file structure will look just like it did before. And the multi-instance and clustering tools are much, much better.

Schedule Task management was re-built from the ground up. Improvements include granular controllers such as: ranges, conditionals, triggers and chaining, priority, grouping, and much more! Schedule tasks can even be application specific.

Dynamic Java Class Loading will allow you to add java classes quickly and to specific applications without putting restarting servers and all that. Lets hope they consider security with this.

Closures are something we have seen in other languages, like jQuery. Simply put, they are anonymous functions that execute in caller context. In CF you can use closures in function arguments, function bodies, and as vars in CFSCRIPT. Advanced developers will love this new feature.

Security is not only improved in the app, but Adobe has supposedly taken a very serious stand on security. They have new security czar and a new head QA engineer whose responsibilities include ensuring the security of the CF product. Updates will be schedule quarterly to ensure a regular maintenance schedule and right from the server update tab. No more will you have to go to the Adobe site to find updates, in can be done all in the application. Multiple servers? Update all fixes across all servers with one click!
The security of ColdFusion has always been a bubear of mine, as a host it is frustrating when you cannot lock things down, and I have contributed quite a lot of feedback and advice in this area over the years, so lets hope they finally get it right this time.

Security improvements are slated to include:

• session fixation, CSRF protection, new functions
• password encryption, & enhanced security (sessions & cookies)
• new xss & CSRF functions
• new algorithms
• CF Admin is secure by default on install

by Rob Brooks-bilson

Building High Performance Applications with ColdFusion 9 and Ehcache 2.4 Take a look around at any high performance website such as Facebook or Twitter, and regardless of the operating system, application server, programming language or database it’s built on there’s one thing you can be fairly certain of – the extensive use of caching.  Regardless of how fast your sharded and clustered MySQL database is or how sweet your NoSQL backend, caching can provide a performance boost, often one or more orders of magnitude faster than you could ever achieve without it.
Implementing caching in Adobe® ColdFusion® 9 is simple and easy.  When Adobe released ColdFusion 9.0, they included a stand-alone version of Terracotta’s Ehcache (version 2.0 to be specific).  If you’re not familiar with Ehcache, it’s widely considered the de-facto caching solution for Java applications.  It comes in both open source and commercial versions with varying levels of capability and support.

Read the full article here

Read more...