To .WAR or Not to .WAR?

A week or so ago, Matt Woodward posted a blog entry detailing how to install Railo and Open BlueDragon on Tomcat. Since then I’ve been experimenting with installing not only Railo and Open BlueDragon into Tomcat, but Adobe ColdFusion 8 and MX 7 as well. I’m trying to determine if this configuration is better for me as a consultant that works on a variety of customer projects on various CFML engines.  I’ll leave that discussion for a future post as I’ve not decided quite yet what I think.

One thing that this experimenting has me thinking a lot about, however, is the “organization” of the code base for our projects. Here’s the question that I’m working through in my head at the moment.  Should we be organizing our application code so that it can be packaged up in a WAR file–whether or not we ever expect to deploy our application as a WAR? I realize that everyone has a different “pet” way they like to organize their project code–I myself have been using a certain standard folder structure that I like for a couple years now.  However, my folder structure would not work if you wanted to take my application and package it up as a WAR file that included a specific CFML engine.

As an example, I have been including a /conf directory (for framework XML config files etc) in my project structure that is at the same level as my /html directory (this functions as my web root). Most of us have most likely heard people advocating this structure because it puts the XML files outside of the web root and thereby protects people from being able to browse our XML config files directly to view sensitive configuration data for our applications.  This particular organization would break since the context root as defined in the WAR file needs to be the directory that includes my web files (/html in this case). So, I would need to reorganize my project so that any files that need to be deployed via the WAR file would reside under my /html folder.

I’m VERY new to the whole Java servlet container scene, and therefore I obviously don’t know what is possible in the Tomcat configuration files that might address this issue. I suppose it might be possible to use the configuration options in the web.xml or context.xml to modify your project structure, but right now I’m not familiar with how to get this accomplished.

What do most shops do when developing a new application that could be deployed on any given CFML engine? Should we be trying to use the standard Java WAR method or continue to use the methods we’ve all been using to now deploying individual files to a web root on a server?

I’m leaning toward rethinking my project organization to allow deployment via WAR files and using some sort of process in an Ant build script to include a specific runtime depending on what CFML engine is required for the project (or none at all if it is to be deployed as simply files under a web root). Any thoughts or suggestions?

Leave a Comment