What is Best Practice for persisting configuration settings in EAR files?

Question

My application is deployed as an EAR file.

The application has traditionally required that some post installation configuration changes be made.

This was easy with the Oracle 10G OAS as the EAR was exploded into a directory thus allowing easy access to configuration files.

With 11G, the EAR is not exploded resulting in additional documentation on exploding, modifying, and recombining the EAR.

It seems to me that this must be a relatively common problem with a solution, perhaps a standard one through J2EE, that I have simply not come across or recognized it as the solution I was looking for.

Some alternatives include: 1) Providing a utility that will modify the EAR file prior to deployment. 2) Store all configuration settings in a separate location. 3) Store all configuration settings in a database; access the database via a container provide connection exposed through JNDI.

But is there an established best practice?

Lacking that, what approach has worked for you?

Thanks Curtis

Answer 1

I have done some significant work around this subject with one of my clients. In a nutshell (which I believe should help you):

If you were to use configuration files, placing configuration files inside the EAR (through exploding / re-packaging) has the drawback of having your EAR files non-portable between different environments (for example, QA environments vs. Production environments). Over time, this increases overhead and there's always the odd chance of confusion between environments. Such approach is only viable for configuration items that are environment agnostic - that is, remain the same across all SDLC environments (QA, test etc).

Alternatively, you could place these files in a separate directory and add that directory to your server's classpath. This is done differently in each application server; in WebSphere, this is done using the "shared libraries" facility.

An approach that worked for us better, over the long run, is to use what J2EE technology actually designated to use for such tasks - using resource environment entries, accessible via standard JNDI mechanism under the java:comp/env namespace.

I would prefer the resource-environment entries' approach over anything else... after trying out pretty much any possible solution.

Answer 2

As far as I know, this is still one of the pain point, and your analysis is mostly correct.

Here is a more elaborated answer I wrote long time ago on java.net forum to a similar question, but we were using Glassfish.

I haven't heard of any fundamental changes in the spec when it comes to this issue, but there might be some Oracle AS specific thingy that helps.