Designing ColdFusion Applications for Deployment as EAR Files

I know I already posted about this article and placed a link in there to the Adobe site, but I am planning on adding some additions to this article so decided to copy it in anyway, so I have a point of reference near when I write some additions to the article.

Enterprise Application aRchive (EAR) files are a standard and portable manner for packaging applications to be deployed on J2EE application servers, such as Adobe JRun, BEA WebLogic, and IBM WebSphere. An EAR file is, in essence, just a big ZIP file with a special layout of the directory tree inside that contains a full application (see Listing 1). EAR files have a well-defined format and make Java bytecode truly portable. The same EAR file that we compile and build on our i386 Windows laptop can also run on a 64-CPU mainframe running commercial Unix.

application.ear

• META-INF
  • application.xml
• contextroot.war
  • CFML source
  • HTML sources
  • CSS
  • images
  • WEB-INF
    • web.xml
    • ColdFusion runtime

Listing 1. Directory structure of an EAR file

As you can see from this directory structure, an EAR file deployment for a ColdFusion application can include both the CFML source code that you write and a complete ColdFusion server runtime. It's important to note that even when stripped of all documentation and images, an EAR file can be quite large--over 50 MB, not including your source code.

In this article you will learn why it is beneficial to deliver your ColdFusion applications using EAR files. We will also explain what to watch out for when you design applications that you are planning to deliver in an EAR file.

Requirements

ColdFusion MX 7 Enterprise

• Try
• Buy

Note: You will need install the ColdFusion multiserver installation. This option is available in the licensed Enterprise Edition, the Developer Edition, or in the 30-day trial edition of ColdFusion MX 7. This requires that you download the trial or purchase the Enterprise, Evaluation, or Developer Edition. You must select "multiserver configuration" during the installation process.

Apache Ant

• Download Apache Ant

Prerequisite Knowledge

• Basic understanding of ColdFusion
• Basic J2EE knowledge

Advantages of EAR Files

There are many reasons for using EAR files to deploy ColdFusion applications for your customers. Not all are applicable to all customers, but there are generally benefits for everyone.

On the business side, J2EE is a standard technology that has a lot of traction. If your customers already have a J2EE environment, ColdFusion will fit in without changes to their infrastructure. If you want to, you can even position ColdFusion as a 4GL language for rapid application development. All that the server administrator sees is an EAR file; it may be big but an EAR file is like any other EAR file. This advantage can open a whole new market that was previously the exclusive domain of Java shops.

On the technical side, EAR files can provide more than just a format for delivering your code. Because EAR files can include the complete ColdFusion runtime, you can also package additional components like database drivers and preconfigured ColdFusion runtime settings. This means that you can deliver your application to your customer with far fewer instructions for installation and configuration--greatly reducing the risk of a deployment error.

Combined with the J2EE underpinnings, using EAR files makes it easier to deploy your application in more than one instance on one or more servers. You also have the option to combine these instances into a cluster that provides fault-tolerance and increases the scalability of the application you are deploying.

From a support standpoint, we have all been there: A customer reports that the latest patch doesn't work. After several hours of frantic debugging, you discover that the issue is that the customer never installed a previous patch. However, if you deliver your application as an EAR file, you can ensure that the customer has installed the latest version of every file because each EAR file you deliver contains the entire application.

Challenges to Deploying Applications as EAR Files

There are challenges to delivering your application as an EAR file. Some of the aforementioned advantages can, in other contexts, become disadvantages. For instance, because all the code is compiled and packaged in the EAR file, the customer cannot tinker with it. This also means that you cannot tinker with it after preparing it. If you frequently have to add last-minute, one-line adjustments to your code during deployment, you might find yourself at a disadvantage.

Likewise, creating EAR files requires that you own the ColdFusion Enterprise Edition. You can still develop and build your application using ColdFusion Developer Edition on your local host, but for deployment you must own an Enterprise Edition license for every two CPUs on which you deploy your application. EAR deployments will not work on ColdFusion Standard Edition.

The biggest challenge is how your application interacts with its environment. Because you are delivering a self-contained application, you must be sure to put everything in the EAR file--code, HTML, CSS, additional components, and so forth. Deploying the application should require as little configuration as possible, both to make it easier for your customer and to reduce the chance of something going wrong.

For interaction with the web server, the most important issue is that you pick the right context-root. The context-root is the subdirectory under which the application is located. By selecting different context-roots, you can deploy multiple applications on one website. Putting your application in a subdirectory also enables you to handle uploaded user content gracefully (such as avatars on a forum): You can upload them to a sibling directory of the application so the web server can process them directly. Don't be greedy and use / as the context-root. Because you don't know if the person who deploys your application is going to use an empty J2EE server instance or not, you should develop your application to run always inside a context-root. All paths in your application should be relative to this context-root. When you create your application, choose a context-root so that the name is unique on the deployment server; don't use any common names, such as "admin."

Some of the challenges require you to think about your application in a whole new way. When you package your application as an EAR file, the J2EE server has to expand the application before it can run it. Some J2EE servers, like JRun, do so automatically, which adds some overhead the first time it starts. Others, like WebSphere, require the server administrator to expand the EAR file manually when deploying on it. J2EE servers that expand the EAR file automatically do so to a temporary directory and start the application from there.

One side-effect of this is that the application no longer knows where the EAR file is located; the application knows only the temporary directory to which it was extracted. As a result, when you change something using the ColdFusion Administrator, it ends up in the temporary directory and not in the EAR file. Therefore, if the server administrator moves the EAR file from one server to another, the application will lose any changes that you have made using the ColdFusion Administrator. Even worse, if the operating system deletes all temporary files upon reboot, you will lose all your changes to the ColdFusion Administrator just by rebooting the system. Luckily, this is largely a theoretical problem. Still, if possible, deploy your application as an expanded EAR file. Be mindful of this issue, because even when deploying an expanded EAR file, it will affect your settings when the server administrator moves the EAR or you release a new version.

Another way this becomes a problem is in the use of ColdFusion mappings. When ColdFusion starts from the temporary directory, it automatically updates its internal mapping to CFIDE to point to the temporary directory from which it is executed. All the other mappings will not be updated, however.

Building an EAR File

Now that we are done reviewing the benefits and challenges of EAR files, let's get to work and build one.

Building an EAR File Using the ColdFusion Administrator

The easiest way to create an EAR file is from the ColdFusion Administrator:

1. Open the ColdFusion Administrator.
2. Select the J2EE Archives (ear/war) menu option.
3. Fill out the two-page form and ColdFusion will create the EAR file.

You can find all of this in the ColdFusion LiveDocs.

When you build an EAR file, consider carefully what exactly you want to include. The ColdFusion Administrator gives you some control over the basic settings.

You can include the Administrator, disable debugging, include the source code, and even include third-party components. For example, if you need to include the PostgreSQL JDBC driver, you can include it in your EAR file simply by putting the JAR file in the cfusion-ear/cfusion-war/web-inf/cfusion/lib directory. It will be included automatically when ColdFusion generates the EAR file. Don't forget to include a copy of the license for every third-party component with your EAR file.

Automatic Generation Through Apache Ant

Apache Ant is the de facto standard for automated building and deployment scripts in the Java world. You can use it to run your custom buildfiles to build an EAR file exactly as you need it. In fact, that is exactly what the ColdFusion Administrator does behind the scene. If you look in the {jrunrroot}/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/
packages/compiletest directory, you can find the Ant buildfile that was used by the ColdFusion Administrator when you built your EAR file from the ColdFusion Administrator.

Preconfiguring EAR Files

As we explained in the challenges section, it is important to put as much configuration in your EAR file as possible. When you include everything that your application needs, it provides the easiest experience for your customers.

Build-Time Configuration

When you use a custom build process through Ant, you can set many more options at the time you generate your EAR file by writing them to the appropriate XML file and including that XML file with your EAR file. If you look under the packages directory again, you will see that there are examples of XML files to include with your EAR file. Import them into your version control system and adapt them to your needs. Table 1 lists the XML files you need for the most common settings.

Table 1. XML Configuration Files for Various Settings

Setting	Location
Search Engine Safe URLs	web.xml
Debugging	neo-debug.xml
Requesting timeouts and threads	neo-runtime.xml
Logging	neo-logging.xml
Application variable settings	neo-runtime.xml
Session variable settings	neo-runtime.xml
Missing template handler	neo-runtime.xml
RDS security	neo-security.xml
Scriptprotect	neo-security.xml
Migration wizards	adminconfig.xml

As you can see, some important categories of settings are missing, including data sources, mail servers, and mappings. That is because you typically cannot add them at build time; you must add them later.

Deploy-Time Configuration

There are some settings that you cannot include at build time because you don't know the information yet. For instance, LDAP servers for authentication, SMTP servers for e-mail, and data sources differ from deployment to deployment. Configuration of those settings is part of the deployment process.

The easiest way to add configuration to the deployment process is to provide a wizard when the user deploys the EAR file to a J2EE server for the first time. The wizard asks for all the settings you need and uses that Admin API to configure ColdFusion. Obviously, you need to limit access to this wizard--for instance, to localhost and the IP address of the server itself. But as we explained in "Challenges to Deploying Applications as EAR Files," the settings you change this way are not guaranteed to persist, because if ColdFusion is deployed as a compressed EAR file, the files will be written to a temporary directory. To make sure the settings persist, you must write them to another location.

This has always been a problem in the J2EE world. One of the ways to solve it is to write the settings to a .properties file in a location that is in the class path. To do so, you must ask the user running the wizard to enter a local folder in the classpath. With a cffile action, you can place a properties file in the classpath with the settings that a user has entered in the wizard. In that file, you can then save the configuration of the mail server, data sources, LDAP server, and so on.

By placing this properties file in your class path, you will be able to read these properties later without knowing the final placement of the file. To do this, you need one Java class that reads the properties and passes them to your ColdFusion application. Java classes can access these properties files and read them. This way you can pass the properties to ColdFusion and use them in your application.

There are a few reasons why you would want to put the properties in the class path:

• To make sure the default settings will still be available when you deploy a new EAR file
• To make sure the settings for your ColdFusion Administrator can be restored when the application is restarted

Finally, your application must check if the properties are known to the JVM. If not, the application must run the wizard again and ask the user for those settings.

Application Start-Time Configuration

As we explained earlier, some settings such as mappings can be set only at application start time because they may change until that moment. The way to do so is to set mappings on the fly in onApplicationStart in combination with the Admin API. Because the Admin API is in the CFIDE directory and the mapping to the CFIDE directory is updated automatically by ColdFusion, you can still access it.

If you want to use the Admin API from your code, however, you will need the password. This means you have to hard-code the Administrator password into your EAR file. Because you cannot change the password in the EAR file, you have a potential security leak: every copy of that EAR file will have the same hard-coded password. One way to protect against this is to leave the ColdFusion Administrator out of your EAR file and provide your own administrative interface using the Admin API, making it accessible only from localhost--and offering access only to those settings of ColdFusion that you want your customers to be able to change.

Obviously this is also the time to apply all the settings you wrote to the .properties file at deployment time. Since the .properties file is in the classpath, you can use a native Java class to read it.

Where to Go from Here

As you can see, the decision to deliver your application as an EAR file requires careful thought. You have to design your application while keeping J2EE servers, context-roots, the locations of files, and how you are going to configure your application in mind. We have touched on the basics of a three-stage configuration method that allows configuration persistence through application updates.

• In the first stage, you customize the EAR file as much as possible with all the settings you know beforehand. These settings include debugging, timeouts, script protection, Java classes added to the classpath, and so forth.
• In the second stage, you create a configuration wizard that will ask the administrator for settings regarding the mail server, data sources, scheduled tasks, and permanent storage when the application is started the first time. Although you can apply these settings immediately, you must write them to a .properties file in the classpath, outside the EAR file and temporary directory so the settings will persist.
• In the last stage, you add settings that can be automatically derived to onApplicationStart so they will be recreated whenever the application starts. This typically includes everything that relates to physical paths on the server, like mappings and temp directories. At this stage you must also check for the existence of a .properties file with configuration settings previously saved in the second stage.

Our solution is not the only way to create and deploy EAR files and solve configuration issues. Most J2EE servers offer their own custom extensions for dealing with this problem. If you know beforehand the J2EE server to which you are developing, we suggest checking its documentation for best practices for that server.

To learn more about deploying EAR files, see the following resources:

• Managing Clusters and Packaging Apps Easily in ColdFusion MX 7
• ColdFusion LiveDocs: Deploying ColdFusion Applications
• ColdFusion LiveDocs: Packaging Applications in J2EE Archive Files
• ColdFusion LiveDocs: Using the cfcompile Utility

About the authors