We had the same issue and we compared the following strategies
1. Configuration files embedded in the .jar or .ear that are loaded as resources
2. External files loaded with the java.io.* package
3. Use the database to store the configuration
4. Use JMX/MBean for configuration
5. Use custom JNDI resources
Pro/cons of the above approach
1. Very easy to use, but needs a fresh deployment each time you change the configuration. It's impossible to have one single artifact (.jar or .ear) deployed in different environment.
2. Loading file with java.io.* is discouraged by the EJB specs. There is always the problem of the file path (UNIX vs. Windows environement, etc.) and clustering.
3. Storing the configuration in database may be fine if you have a list of key/values. Storing structured configuration files such as XML is possible in a CLOB, but then it's not easy to update and manage. There is of course the problem of the network traffic.
4. Regular MBean needs to be registered by your J2EE application during runtime, the value will not be persisted automatically (well, there is the PersistentMBean interface that I haven't investigated, but this doesn't seem to be a widely used approach). Custom MBean are Glassfish specific but are deployed once using the console and changes are persisted automatically. However, accessing an MBean is still a bit complicated, and I don't know if that's efficient. Using MBean in unit test is not so easy.
5. Use custom JNDI resource. You can create a custom JNDI object factory
that created you configuration based on a file. The resource can be injected in you bean using annotation. If damn easy to simulate in unit test. The JNDI properties can be edited using the web console.
We decided to use solution 5 and create a JNDI object factory that returns XML loaded from a file. The location of the file can be specified using the console. We have a setter method that is annotated with @Resource and that parse the XML into our final configuration object. To ensure the file is not loaded hundreds of times, we load it once in the object factory. If you are within a cluster, there is probably a way to replicate the configuration file automatically (maybe put them in domain/lib/classes).
This is (from my point of view) an elegant way to clearly separate the configuration information from the way it is loaded. It is indeed possible to later change the JNDI object factory to implement another strategy. Plus it's easy with unit test.
But I would be very interested to learn how other people have tackled this issue...
[Message sent by forum member 'ewernli' (ewernli)]
http://forums.java.net/jive/thread.jspa?messageID=256113