Thursday, March 01, 2007 article on ColdFusion and JavaEE

I found this interesting article by Kola Oyedeji on He talks about integration between ColdFusion and JavaEE and how this could be of interest to JSP developers.
We in our team here have discussed it so many times that why can not ColdFusion be used by J2EE/JSP developers or enterprises that standardize on J2EE. ColdFusion is a pure J2EE solution, runs on all the major applications servers, is so feature rich, so productive that it should be a no brainer for everyone to adapt this. And to this when I add the features that we are adding in Scorpio, it makes even more sense. I don't think there is any other platform which can come even close to CF in terms of features and productivity.
At MAX, I had a conversation with one of our customers and he said something very interesting. His client wanted a pure J2EE solution and his competitors were asking for nearly 6 months to implement this. So this guy did everything in CF, bundled it as an ear (that can be deployed on application server) and shipped in flat one month !! And his client never ever thought that this was a CF application. :D

Good to see this kind of article on a java website.


cfJeff said...

I have never bundled a CF app as an EAR, so forgive me if this is an ignorant quesiton. You can build in CF, Bundle as an EAR, and deploy on any supported J2EE server? CF doesn't have to be installed on the server your deploying too?

Kola said...

Thanks Rupesh

Glad you liked my article


Damon Cooper said...

Hey Kola, no, CF will package the required runtime libs in the EAR/WAR now for you, as of CF 7.0. Just package, deploy, and go!

You do need a CF runtime license for each server machine a CF app runs on (asked for in the J2EE EAR/WAR packaging tool), but we have to make money somehow, right, since the Devlopment and packaging of the app is free with Developer Edition).

That's all here is to it. And CF can pre-compile your CFML into Java byte code in the packaging process as well, so you're not deliivering source code if you don't want to. You can also code to the Admin API and (on first-time up, for example), prompt for the DSN info to configure your app on the fly in it's new home, wherever it's deployed.

So, just write, package, deploy and go!

(And don't have ot tell anyone it's written in's just a smokin' fast, all Java app that runs on any app server as far as they're concerned)