Why reinvent the wheel when you can easily run your CFML applications on any J2EE server?

If your team is considering or being forced to move to J2EE (WebLogic, WebSphere, JBoss, Tomcat, etc.), it may be helpful to know that you don't have to throw away or even rewrite your CFML applications. Some people may want you to rewrite them, and as a long-term goal it may make sense in some cases, but did you know that CFML can run, as-is, on the J2EE server?

It really can be as easy as 1-2-3. If you've not seen it done, or you're skeptical - and especially if you've tried it with CFMX - I'll show you an alternative that you may not have seen before.

Why CFML on J2EE? Even for Skeptics
In my April 2004 ColdFusion Developer's Journal column, I wrote about the many benefits of deploying CFML on J2EE. Indeed, many folks expressed surprise to learn how much they could gain simply by running their CFML apps on a J2EE server - even if they'd never worked with J2EE before. It's still just CFML, supercharged!

If you're a J2EE developer or administrator who's been handed this article by a CFML fan hoping to keep his apps alive while following your architectural and software engineering direction, I, too, hope to persuade you. I appreciate that J2EE folks may have strong objections to considering the notion. You may not see a place for CFML in your organization.

But if the CFML is packaged as a standard J2EE Web app, do you really need to debate semantics? This solution allows you to work together to decide when (or if) to rewrite the CFML as a JSP/servlet application - while reaping all the benefits (for both J2EE and CFML folks) of running the CFML as a standard J2EE Web app until then.

In this article I want to demonstrate just how easy this can be. Whether you're an old hand at deploying J2EE Web apps, or have still not even installed a J2EE server, or perhaps don't even know what a J2EE server is, I'll show you how you can go from having a CFML application to having it run on a J2EE server in three quick, easy steps. It can literally be just a matter of drag, drop, and deploy.

BlueDragon/J2EE: A New Alternative
At this point some of you may balk; you wanted to see how to deploy CFML using Macromedia's ColdFusion MX Enterprise. That solution has been covered extensively both in previous CFDJ articles and in Macromedia's DevNet, documentation, and technotes. I pointed to many of these sources in my previous article (CFDJ Vol. 6, issue 4).

Here, instead, I'd like to show you an alternative, and one that may be new not only to J2EE folks who think ColdFusion is the only way to run CFML, but even to many CFML developers. More important to this article and to those deploying on J2EE, it's easier and more standard as a means to deploy CFML as a J2EE Web app.

BlueDragon, from New Atlanta, has become more and more familiar to many in the CF community. Just as J2EE developers can choose from many J2EE servers, now CFML developers can choose from more than just Macromedia ColdFusion MX as a solution to run their CFML. It's not a repackaging of ColdFusion (more a reverse-engineering effort), but the point is that your CFML simply runs on this alternative engine, which in the case of BlueDragon/J2EE means that your CFML runs as a J2EE Web app. No ColdFusion is required (and indeed no BlueDragon server is required, as it's just a J2EE Web app).

If you can hold your skepticism at bay, and wait a few moments for answers to your questions (price, performance, compatibility, legitimacy, etc.), I'd like to start by simply showing you the three-step deployment process. Folks who've tried to deploy on, say, WebLogic, WebSphere, or Tomcat using ColdFusion have always been very surprised at how easy this alternative is.

Download Free Trial/Developer Edition
To get started, simply visit www.newatlanta.com/bluedragon. It's a very rich site and you should eventually take the time to review the many available resources (all the documentation is available free online, and there are many self-help resources, including tag compatibility and feature comparison charts, configuration and requirements info, pricing info, FAQ, and more). There's also a very supportive mailing list staffed by New Atlanta engineers, with a searchable archive to review past discussions.

To check out the J2EE deployment solution, visit the downloads page (www.newatlanta.com/c/products/bluedragon/download/home). There are four editions of BlueDragon (two stand-alone server editions and the upcoming .NET edition, in addition to the J2EE edition). You'll want the J2EE edition for this article. (If you're interested in .NET instead, the .NET edition will allow you to deploy CFML on .NET. We make CFML the only language to deploy on both J2EE and .NET! More on that in an upcoming article.)

All editions are available free for trial and development. In the case of the J2EE edition, it comes first as a single-IP developer edition with no expiration date. Feel free to use it against any J2EE server you have and have your developers get started with seeing how easy deploying CFML on J2EE can be. (I say "any" because all of the major J2EE servers are supported, and BlueDragon has worked with every server tested so far. See the New Atlanta Web site and/or documentation for a current list of tested servers.) You can arrange to receive a 30-day trial license key with no IP limitations. And after the trial (or if you don't bother to get the trial license), you can continue to use the developer edition to test/create code for exploration or for deployment for production with a production license key.

No Installer. No Wizard. No Server. Just Zips and WARs
When you select the J2EE edition to download, you'll see that it's just a Zip file available either as a self-extracting exe or .zip/.tar file, depending on your operating system. You can use the Zip file on Windows. Regardless of which approach you use, notice that there's no installer as with ColdFusion MX Enterprise's J2EE deployment. (Indeed, that's why it's a single-IP developer edition to start, since it's just a static Zip file that all downloaders use, so there's no license key embedded. You can easily add a licence key if you arrange to receive one.)

Just extract this Zip file to your workstation or server into the directory of your choice, as shown in Figure 1, where I've named it BlueDragon_J2EE. This isn't where the code will run. In fact, J2EE servers have a notion of deploying Web applications onto the server, so this directory will serve more as a starting point from which you'll begin the drag-and-drop process.

Notice that the directory contains mostly documentation in the form of PDFs and a couple of .txt files. Check those out after reading this article to learn more. The only two things other than docs are in fact the real meat of the BlueDragon/J2EE deployment process.

First is an available BlueDragon61.war file. Second is a BlueDragon_webapp_61 directory. You can use the first as a quick demo and the second as a model Web application with which you can deploy your own CFML application. Those who've tried to deploy on J2EE using CFMX will be surprised to see that the BlueDragon Web apps have a much smaller footprint than CFMX's version: about 10MB versus 70-110MB for CFMX.

For newcomers to J2EE, Web applications (typically JSPs and servlets) are packaged into a directory structure with certain key characteristics, notably a WEB-INF subdirectory and a web.xml file. Each of those exists in the BlueDragon_webapp_61 directory, and in the BlueDragon61.war file, which is really nothing more than a Zipped version of that directory structure, renamed as a WAR file.

Deploying BlueDragon/J2EE on Your J2EE Server
Here's where the drag-and-drop deployment process begins. You can take either the Web app directory or the WAR file and simply deploy it as-is on the J2EE server of your choice (or servlet engine, for those who know the difference). This is another difference from CFMX; not only was there no installer, but there are no steps to perform before deploying the Web application.

For a moment, let's not even worry about deploying your particular CFML application. The BlueDragon Web app as downloaded from New Atlanta has in it a sample index.cfm file that just does some basic things like calling a custom tag (as well as Java and C++ CFX custom tags) and doing a CFDUMP. It can be used to determine if indeed the app, once deployed, is allowing CFML to run. Later I'll show you how to deploy your own CFML just as easily.

For now you can just take the WAR file (BlueDragon61.war) and either deploy it yourself (if you're running the J2EE server yourself) or give it to your J2EE administrator to deploy (e-mail it, FTP it, copy/paste it to a directory). Again, it's just a J2EE Web app. If you're not familiar with the concept of deployment, I'll explain that momentarily.

For those familiar with the concept, let me just say that the fact that the Web app's got a CFML page in it (and soon, your entire application), along with some files that run the CFML, should be immaterial and transparent to the J2EE folks. It could just as well contain the JSPs and servlets they'd normally expect; indeed, there's a sample JSP in there as well.

You may know that once the Web application is deployed, the J2EE server will know what to do with the JSP page. With BlueDragon, the entries in the web.xml file and other files in various subdirectories of the Web app will enable the CFML to run on the J2EE server.

The Concept of Deployment in J2EE
I keep using this word deployment. If you're new to J2EE, you may be confused. Those used to running CFML on a Web server on Windows or *nix will more generally be used to simply dropping a directory of CFML into the docroot of a Web server (like IIS or Apache), where the Web server has been configured to integrate with ColdFusion (or BlueDragon). At most you may create a new virtual directory or virtual host/Web site to point to the CFML, but there's no real concept of deployment.

With J2EE servers, things work differently. Actually, there are a few ways they can work, depending on whether you're using an external Web server like IIS or Apache or are just leveraging whatever built-in Web server exists in the J2EE server, and whether you're using EAR (enterprise archive) files or WAR (Web application archive) files.

The concept of deployment of a Web application can be nearly as simple as dropping a Web application directory into a particular place, but it generally involves extra steps taken by the app server under the covers. In the end, though, you still end up with your Web application ready to be called from a browser, perhaps using a particular port or context path, which is similar to a Web server mapping.

But what, then, does it mean to deploy a Web app on a J2EE server? In some cases, it's really no different than dropping the application into a particular directory on the J2EE server, which automatically deploys the code for you. In other cases, you may need to use an administrative console to deploy the app.

The actual steps vary. Some J2EE servers permit you to drop a Web app into a particular directory to auto-deploy it, or they may allow it only if the J2EE server has been set up in development mode. Servers permitting such drag-and-drop deployment include WebLogic, JRun, Tomcat, and ServletExec. Some servers (like JBoss) will let you drop the Web app into a particular location to auto-deploy, but it must be a WAR file (or, curiously, a Web application directory named with a .war extension).

Each of these has an admin console that can be used as well. WebSphere, prior to 5.1, on the other hand, can deploy a Web application only by use of its admin console. Fortunately, you can find a discussion of the vagaries of most common J2EE servers in the appendix of the BlueDragon document, "Deploying CFML on J2EE Application Servers."

Deploying the Sample WAR File
I'll explain the process of deploying the sample WAR file on three common servers: WebLogic, JRun, and Tomcat.

For WebLogic, let's assume that you have it installed on a Windows machine in the BEA directory. If you've left it configured in its most basic way, there will be a directory such as C:\bea\user_projects\domains\mydomain\applications\ where Web apps can be deployed. This is depicted in Figure 2.

You can simply drop the BlueDragon61.war example Web application into this applications directory. After doing so, and waiting a few moments (depending on the speed of your system and other activity in the server), you should be able to browse its sample index.cfm file using whatever port you use for WebLogic, using the name of the WAR file as the context path. So if you browse this WebLogic server as port 7001, and you dropped the file as named above, you could browse the index file as:

http://localhost:7001/BlueDragon61/index.cfm

That's it. The sample CFM file is now running on WebLogic. Of course, this is just the sample WAR file. In the next section I will show you how to deploy your own CFML. Also, you may wonder if you can have a context path other than BlueDragon61. You certainly can. Just rename the WAR file before dropping it into the applications directory.

The same approach applies to JRun and Tomcat (among other servers). You just need to know where to drop the WAR file or Web app. In JRun, assuming you've installed it in C:\JRun4, and have configured the default server, you drop it into C:\JRun4\servers\default\. In Tomcat, assuming you've installed it in C:\Program Files\Apache Group\Tomcat 4.1\, you'd drop it into C:\Program Files\Apache Group\Tomcat 4.1\webapps\.

It's really that easy! Try it on your J2EE server of choice. Heck, try it on more than one. The same Web app can be deployed unchanged on each of these servers. This is another powerful benefit of the BlueDragon approach. Note, again, that in WebSphere prior to 5.1(or optionally in these other servers), you can use the admin console to deploy the Web application, as demonstrated in that appendix of the BlueDragon manual, "Deploying CFML on J2EE Application Servers."

Changing the Context Path
You may be wondering how you can deploy the Web application so that it uses something other than the name of the WAR file or Web app directory to be the context path for the deployed Web app. For instance, perhaps you want it deployed as "/" so that it appears to be the root of the server. You can do this, but the steps are different for different J2EE servers.

In the case of WebLogic, for instance, you'd need to create (or edit) a weblogic.xml file in the WEB-INF directory of the Web application, placing in it the following lines:

<weblogic-web-app>
<context-root>/</context-root>
</weblogic-web-app>

Notice that this is setting the context path to "/". Just be sure not to choose a path that would conflict with any other Web application you've deployed.

In JRun, you would instead edit jrun-web.xml in the WEB-INF directory of the Web application, using a similar entry:

<jrun-web-app>
   <context-root>/</context-root>
</jrun-web-app>

In the case of Tomcat, you would make a change to the single conf/server.xml file for the entire server (under the Tomcat install directory), and create a <context> entry naming the desired path and pointing to the deployed Web app. So assuming we deployed the BlueDragon61.war file, but we want to access it as "/" instead of BlueDragon61, we would use this entry:

<Context path="" docBase="bd61test"/>

For information on setting the context path in another J2EE server, see the appropriate documentation for that server.

Deploying Your CFML Application
While the previous example demonstrated use of the sample WAR file offered with BlueDragon, you'll naturally want to see it work with your own Web application. Here's where it really is just more drag-and-drop simplicity. You'll use the other of the two sample Web apps, the BlueDragon_webapp_61 subdirectory, which is the same as the WAR file, except that it is open (uncompressed) so you can see what's inside and add files to it.

Indeed, one of the simplest ways to demonstrate deployment onto CFML is to just copy your CFML from where you have it deployed now (perhaps the docroot of your development Web server) and paste it into the root of that BlueDragon_webapp_61 Web application directory.

Since you may want to do this often, you should duplicate the BlueDragon_webapp_61 directory in place (rename it to something preferable as a context path once deployed) and then simply copy your CFML into it.

Deploying the CF Example Apps
As an example, you can copy the example application code that comes with CFMX. It's found in cfdocs/exampleapps (and may be currently installed in your Web server docroot). We don't need the other directories under cfdocs, but the code in the exampleapps directory does expect to be found in a subdirectory of cfdocs.

So let's duplicate the BlueDragon_webapp_61 directory (as discussed above) and then rename it to bddemo. You can call it anything you like. Its contents would look like Figure 3

Notice that it has a WEB-INF directory, which contains the elements needed to run your CFML, as well as a sample index.cfm and index.jsp. The BlueDragon directory is there in support of the BlueDragon admin console (offered in the Web app by default, but removable if you don't want it there).

Let's create a cfdocs directory there (since the code expects to be found in one), and then copy the exampleapps directory (since we don't need all the other directories under the original cfdocs) into that directory. I found my copy installed at C:\Inetpub\wwwroot\cfdocs\exampleapps\. Again, even if you don't have this particular code, use whatever code you have and copy it into the duplicated, renamed BlueDragon webapp directory (see Figure 4).

That's really all there is to it. We can now deploy this Web application (the parent directory, now called bddemo) by simply copying and pasting it into the appropriate directory for the J2EE server, just as we did the WAR file. For instance, if I copy this "bddemo" directory into my C:\bea\user_projects\domains\mydomain\applications\ directory, then after a moment I could browse the example applications on my machine at:

http://localhost:7001/bddemo/cfdocs/exampleapps/index.cfm

See the sidebar "Changing the Content Path" for information on deploying the Web app to run at the root of the app server

Dealing with CFML Incompatibilities
If you try this, you'll notice that it doesn't work at first. You'll get a BlueDragon error, but this isn't a problem with deploying the CFML on J2EE. Instead, it's simply that the Application.cfm in this particular Macromedia written example application calls a template (global_vars.cfm) containing CFML that tries to use the coldfusion.server.ServiceFactory object, which is not available to BlueDragon.

The good news is that you can easily change the code in that file to work on BlueDragon by removing the reference to that particular object. It's only trying to decide whether or not the sample database, ExampleApps, is a Microsoft Access database. You can replace it with the following code snippet (save a copy of the original if you'd like):

<cfscript>
    request.app = structNew();
"#getPageContext().getRequest().getContextPath()#/cfdocs/exampleapps";
    request.app.dsn = "ExampleApps";

    request.app.ucase = "ucase";
    request.app.isAccess = true;
</cfscript>

You may encounter other CFML incompatibilities when you deploy your own code on BlueDragon. It's often a 100% plug-compatible replacement, though some minor adjustments may be needed. If you need the benefits it offers (including easier, more standard deployment on J2EE), then dealing with modest compatibility challenges can be a small price to pay. See the blog entry, bluedragon.blog-city.com/read/601768.htm, for more information on compatibility concerns and the distinct benefits of deploying CFML with BlueDragon.

There are just a few tags and functions that BlueDragon doesn't support. Then too, if you have a CF4 or 5 app, you would experience challenges in moving to CFMX as well. Many of the same tags that became obsolete or were deprecated in CFMX are also obsolete or deprecated in BlueDragon. See the BlueDragon manual CFML Compatibility Guide for more information.

One other concern in deploying CFML on J2EE is a possible need to change code due to the context path. If your code was designed to run at the root of the Web server, again, you may need to change the Web application context root to "/" (as discussed earlier), or to change the code to be more flexible about its location.

There's also the potential concern that some J2EE servers will copy and run the code from a different location than where you place the code for deployment (depending on the app server and how you deploy). BlueDragon comes with some extended tags and functions to help with this challenge, as discussed in the BlueDragon manual Deploying CFML on J2EE Application Servers.

Changing CFML Once It's Deployed
You may wonder where to make the change to this CFML file in the example app, once the application is deployed on the J2EE server. You have a couple of choices. First, you may be able to simply change the file in the deployed Web app on the J2EE server. The location to do that will depend on the server and whether you deployed as a WAR file or open Web app. Again, it's still just CFML. Since I deployed the Web app as an open directory on BEA WebLogic, I can change that global_vars.cfm file as located (in my example) in C:\bea\user_projects\domains\mydomain\applications\bddemo\cfdocs\exampleapps\.

Just as you're used to with CFMX (or BlueDragon) stand-alone server editions, you can still edit CFML once it's deployed on J2EE. Save the changes, refresh the page, and you'll see that the page is reloaded immediately (and many find faster than on CFMX, though of course many factors in a given template and your configuration can influence performance).

Your J2EE administrators may object to your editing the files in the deployed Web application. To J2EE purists, a deployed Web app should never be changed. Instead, you should create (or edit) the Web application outside the server (in your development environment, for instance) and then re-deploy it. This may involve stopping the Web application using the server's admin console, copying the newly updated Web app as you did before, and then redeploying it using the admin console's appropriate options.

Configuring BlueDragon Administrative Settings
The index.cfm page of the cfdocs/exampleapps/, as well as some of the example pages, don't use any database, so they'll run right away. For pages that need the database, you of course need to set up a data source, just as in ColdFusion. You have a couple of options for doing this. Each may appeal to different audiences and situations.

BlueDragon Admin Console
I mentioned before that there is a BlueDragon admin console that's installed as part of the Web application. That's accessible using /bluedragon/admin.cfm after the context path for your application. So for my example deployment of a /bddemo/ application on WebLogic, I'd access the admin console as follows:

http://localhost:7001/bddemo/bluedragon/admin.cfm

As in CF, this will prompt you for an admin password. Just as there is no license key by default (and it's limited to a single IP address until you arrange for a license key), so too is there no admin password defined by default (since the BlueDragon/J2EE Zip file is static, any value we might preload would be no better than loading none at all). When the admin console loads (see Figure 5), you'll see that it's very similar to ColdFusion's.

You can change the admin password in General>license & security, and you can turn on debugging for each page (as in CF) using Debugging>settings. To add a data source, follow the instructions in Data & Search>data sources. Most of the options will be familiar to CF developers and administrators, and there is online help on most pages.

Some J2EE administrators will balk (again) at the notion of making changes in such an admin console, preferring that the Web application not be changed once it's been deployed. We appreciate their concern.

I mentioned that you can remove the admin console from the BlueDragon Web app before (or even after) deployment. Just remove the BlueDragon directory, as discussed earlier. You also need to remove the admin.bda file from the WEB-INF/bluedragon/ directory (within the Web application).

Bluedragon.xml File
You may wonder, then, how you can configure settings such as data sources and debugging. They're all set (some by default, some by way of the admin console) in a bluedragon.xml file, also located in the WEB-INF/bluedragon/ directory. You can edit it directly. One option is to make changes in a development version of the application and review how admin console changes lead to changes in the bluedragon.xml file.

Note that editing the bluedragon.xml or using the admin console is also the way to get the license key implemented once you obtain one. See the option General>license & security in the BlueDragon Admin console. Once you've made these changes, you can now deploy the Web application as discussed above.

Admin Console "Build War File" Option
Still another option is to use a built-in feature of the BlueDragon admin console. See Deploy>build war file. What this does is take the application (whatever Web app the admin console is being executed within) and packages it into a WAR file (another nice feature for those J2EE admins who may want your Web app packaged that way). So you could deploy the application in a development server, make changes to its admin console, and then build the WAR file that would contain both your code and the bluedragon.xml file (and deploy that WAR file into production). More than that, this "build war file" option also automatically removes the BlueDragon admin console files.

J2EE Data Sources
Finally, rather than configure a data source in the BlueDragon admin console at all, you have the option to use J2EE data sources instead. This will appeal to J2EE admins especially. You can define a data source at the J2EE server level, using the J2EE server's admin console (such as WebSphere's or WebLogic's). When you do this, that data source's JNDI (Java Naming and Directory Interface) name is what you then would use in a CFQUERY DATASOURCE attribute. When the code runs, if BlueDragon doesn't find the data source in its admin console configuration, it will look to the J2EE server.

J2EE Sessions
Similarly, you can have the J2EE server manage sessions. In the BlueDragon admin console, under Application>variables, notice the option "J2EE Sessions", which can be set to "yes". By doing so, you will be giving control to the J2EE server to manage sessions, imparting all the benefits you may get from the J2EE server, such as replication of sessions across a cluster, or more simply (but new to many CFers) persistence of the sessions across server restarts. Note also that using J2EE sessions also instantly changes the behavior of sessions such that they end when the user closes the last instance of their browser. This is unlike traditional sessions in CF or BlueDragon, which remain persistent for a very long time because they leverage the CFID/CFTOKEN, which is also used for client variables. Using J2EE sessions tells the server to instead use a JSessionID cookie, which is kept only in the memory of the browser.

Closing Thoughts
I started the article asserting that deployment on CFML can be as easy as 1-2-3. While I've explored a few concerns that could impact some deployments, it is still true that many applications can be deployed on a J2EE server using BlueDragon in just three easy steps:

1. Duplicate the skeletal BlueDragon_webapp_61 and rename it to a suitable context path name.
2. Copy your CFML into that directory.
3. Copy/move that directory into the auto-deployment directory (for J2EE servers supporting that notion), or use the J2EE server's admin console to deploy it.

And, as I discussed in my previous article, you can also use the Web app to deploy multiple times on a given J2EE server, such as in a clustered environment, or just to create different Web apps in the same virtual server, where they can coexist with others without conflict.

J2EE Alternatives
One interesting area where J2EE folks have an advantage over CFML folks is in the available alternatives for running their applications. It's not unusual for an organization to consider several choices when evaluating alternative J2EE servers (or servlet engines, a difference I'll explain in a moment).

If you're in a larger organization, you'd probably lean toward IBM's WebSphere or BEA's WebLogic. If you're an Oracle shop, you'd probably choose Oracle's J2EE server. If you're fans of open source, you'd probably choose Sun ONE, JBoss, or Tomcat, to name a few. If you're a value-driven firm, you may choose Macromedia's JRun, New Atlanta's ServletExec, or any number of other alternatives.

The thing is, folks in the J2EE community have long been open to considering any of several options depending on their size, their needs, their preferences, etc. Still, they knew that any of these servers could do the most basic things they needed, running their JSPs and servlets - which are just the Java way of developing Web applications. As I discussed in my previous article, there's not much JSPs and servlets can do that CFML can't. It's just that they suit Java developers very well, since they're written in Java.

JSPs and servlets were once the sole province of servlet engines (Tomcat and ServletExec are servlet engines), but the J2EE specification and J2EE servers (such as WebLogic, WebSphere, and the like) evolved to do much more (running EJBs, supporting Java Messaging, and many other things).

Java developers (and managers) know that whatever server or servlet engine they choose, their JSPs and servlets will run on it. They can pick and choose, even develop on one server and deploy onto another. The Sun J2EE specification clarifies what JSPs and servlets, and their packaging as J2EE Web applications, should look like. It would be helpful if the CFML community also could leverage a documented specification of what CFML should do. New Atlanta would support such an effort.

If a savvy J2EE administrator wonders whether the 10MB per Web app can be reduced when multiple copies are deployed - by moving some of the WEB-INF files to a directory shared by all Web apps - the answer is yes.

As I alluded to before, it's natural for J2EE administrators, along with CFML developers and their managers, to be skeptical. They've not heard of BlueDragon, and they may have an even greater aversion to CFML in general. Some other common concerns folks will have are such things as price, performance, legitimacy, etc.

Let's address a couple of these quickly. As for price, the developer and trial editions of BlueDragon/J2EE are free. A commercial license lists for $2,499/CPU, with unit prices going down with multiple CPUs, multiple servers, etc. That's less than half the retail price of CFMX Enterprise, which is the edition required to deploy onto J2EE using CFMX. A license is required for any servers on which the BlueDragon Web application (and your CFML) is deployed (other than for trial or development).

As for performance, New Atlanta has not yet published comparisons with CFMX. Customers have reported instances of applications that performed worse when moved from CF 5 to CFMX 6.1 but that performed better on BlueDragon. Still, you may find an instance where an app's performance is less than expected. There are just too many variables that can influence performance to be able to state any conclusive comparisons. New Atlanta is, however, committed to solving any performance problems that can be identified.

As for legitimacy, it's worth noting that while New Atlanta may seem new to many CFML developers, BlueDragon has been out for a couple of years. And New Atlanta has not only been in business since 1997 (with 11,000 customers in 70 countries) but they have established a reputation for engineering expertise and quality support with their server-side Java tools, JTurbo and ServletExec. The former is a SQL Server driver (offered free within BlueDragon) and the latter is a servlet engine that's embedded within the Server/Server JX editions of BlueDragon (the way JRun underlies CFMX).

It's worth noting that if you have not yet chosen a J2EE server, you can get several benefits from considering ServletExec as the server on which to deploy BlueDragon/J2EE. It, too, is available in free trial/developer editions, is priced much lower than most commercial J2EE servers, and comes with all the support New Atlanta has become known for.

But the cool thing about BlueDragon/J2EE is that it works with whatever J2EE server/servlet engine you have. More important, it makes your CFML run on such servers. If you're facing the prospect of having to rewrite/port hundreds or thousands of CFML templates to J2EE, BlueDragon/J2EE may be a very cost-effective solution that protects your investment in CFML and CFML developers.