<< Upselling your architecture | Home | Daylight savings changes - patch your JRE >>
Twitter RSS feed for Simon Brown [Twitter] simonbrown: Eating cream cakes in the sun at jersey zoo ... chillin'

Coding the Architecture RSS feed for Simon Brown [Coding the Architecture] Just a short note to plug a handful of sessions that Kevin and I are presenting at the upcoming Software Architect 2008 conference, 3rd-5th June, London. 1. Coding the Architecture : From Developer to Architect The first is a re-run of our ...

WAR files : to explode or not?

What's your preference?

In Stop the pollution in WEB-INF/classes, Sebastiano talks about the proliferation of configuration files underneath the /WEB-INF/classes directory of Java EE web applications. It's an interesting post and I like the recommendation of placing configuration files in a separate directory. However, it was the first comment that sparked me to write this blog entry.

WAR files are used a lot, in my experience, far more than exploded directories.

Personally, I'm starting to use WAR files for deployment much less than I ever used to, and this is exactly because of the reasons outlined in Sebastiano's blog entry. Now, I prefer to keep the exploded web application directory structure outside of the web container installation and simply link to it instead (e.g. using a separate Tomcat context definition). Problems with throwing a single deployable unit at a web container installation include...

  • Configuration can't be tweaked if needed (e.g. log levels).
  • Application patches are harder to apply.
  • Web container upgrades are more complex.

There's also something more fundamental. Back in the good old days of J2EE, it was quite common to see configuration defined at the application/web server level, utilising JNDI for example. Now, frameworks are pushing configuration back into the web application because it does make for applications that are easier to port between containers. You just have to take a look at Spring and Acegi for examples of how database and security configuration can now reside alongside the webapp, in a container independent way.

This has some interesting consequences, particularly if you need to hand-off a web application to a separate team for deployment into production. Typically, development doesn't have access to the production configuration (e.g. database credentials) so providing an exploded webapp tends to make installation/deployment/customisation an easier process, regardless of whether it's manual or automated.

I'm curious, what's your preference - a WAR file or its exploded form?

Tags :
Responses[13] RSS feed for responses to this blog entry
Posted by Simon Brown on 13 February 2007 10:14:00 GMT #


Reply

Re: WAR files : to explode or not?

Comment from Edward on 13 February 2007 11:46:16 GMT #
Our system uses a combination - we deploy the application as an EAR file, but it is set up to read configuration files from a separate directory. The EAR is only allowed to contain stuff which is the same regardless of which environment it is in.
Reply

Re: WAR files : to explode or not?

Comment from Frank carver on 13 February 2007 12:34:33 GMT #
My personal preference is for a combination. I use this approach very successfully in Friki, and in several WARs and EARs I have built for clients.

Each war file is completely self-contained, and can run by simply dropping it into a container - however, the first thing it does when initialising is to look for a place to put any user-modifiable files. This "looking" process may be something such as a JNDI lookup, or a default web page asking for a directory, a hard-coded external location, or whatever - the details depend on the application and its intended use.

Once the app has found its place, it first checks to see if a set of configs are already there (in which case it uses them), if there are no pre-existing configs, the application extracts a default set to the discovered place and uses them.

For me this gives the benefits of both approaches, the application will run with zero configuration and any "user servicable parts" can easily (and persistently) be modified as needed.

Thoughts,
Reply

Re: WAR files : to explode or not?

Comment from Simon Brown on 13 February 2007 14:00:33 GMT #
I do something similar for Pebble, which means you can run it out of the box using the defaults. It means people can get up and running by deploying the WAR file very quickly. Personally though, I always explode it and tweak some of the config files contained with /WEB-INF.
Reply

Re: WAR files : to explode or not?

Comment from arnaud on 13 February 2007 12:47:54 GMT #
I like the idea of having a war, because it enforces good deployment script and a clean architecture for the storage of the files for example. All the live configuration problem can easily be solved by a JMX Bean. That's the way we solved the log4j configuration problem.
Reply

Re: WAR files : to explode or not?

Comment from Simon Brown on 13 February 2007 13:56:03 GMT #
In my last project, we also exposed the ability to change log levels on the fly using JMX and found it really useful. Unfortunately those changes didn't survive server restarts though.
Reply

Re: WAR files : to explode or not?

Comment from arnaud on 13 February 2007 14:01:27 GMT #
our JMX bean offers the Level changing by category, but we also but the possibilty of loading an external config file, and resetting the default web-app. This way a specific debug file can be store on the server, and it's easy to switch to that. It's probably doable to add a method that export the config as xml or properties.
Reply

Re: WAR files : to explode or not?

Comment from arnaud on 13 February 2007 14:03:12 GMT #
 I should have check my spelling :)
Reply

Re: WAR files : to explode or not?

Comment from Simon Brown on 13 February 2007 14:05:50 GMT #
Oh right, so you can switch out the entire logging configuration in a single operation. Very nice.
Reply

Re: WAR files : to explode or not?

Comment from Emmanuel Pirsch on 13 February 2007 13:03:15 GMT #
In production, I prefer to deploy in WAR and have a separate directory for configuration that a deployer need to access. It's easier this way and it survives redeployement easily.

As for deployer who needs to edit some file inside a WAR/EAR, I've written a Ruby script that allows one to do that without having to extract and repackage everything.
Reply

Re: WAR files : to explode or not?

Comment from Simon Brown on 13 February 2007 14:02:28 GMT #
Now that's what I call a useful script. :-)
Reply

Re: WAR files : to explode or not?

Comment from Sebastiano Pilla on 14 February 2007 09:08:36 GMT #
Thanks Simon for the "manual" trackback, lots of things to learn from the discussion here.
Reply

Re: WAR files : to explode or not?

Comment from Simon Brown on 14 February 2007 09:21:23 GMT #
You're welcome and thanks for writing the original post. I couldn't work out how to send an automatic TrackBack so I did it the old fashioned way. ;-)
Reply

Re: WAR files : to explode or not?

Comment from Stefan on 28 February 2007 00:30:50 GMT #
I prefer the war file and database connections defined in the server config. We ship our war files with a default database config for development but expect the deployment team to configure the app server to provide the database connection through JNDI.
Spring's JndiObjectFactoryBean works very well here including support for a default value.
JNDI is also used for configuration of other properties like the host names, or Hessian base URL:

<bean id="customerService" class="com.xxx.core.support.JndiConfiguredHessianProxyFactoryBean">
  <property name="baseUrlJndiName" value="java:comp/env/coreRemotingUrl" />
  <property name="defaultBaseUrl" value="http://localhost:8080/core/remoting" />
  <property name="serviceName" value="CustomerService" />
  <property name="serviceInterface" value="com.xxx.core.service.CustomerService" />
</bean>

which allows overriding the default in tomcat's server.xml (or whatever app server you use).

Add a comment Send a TrackBack