J2EE EAR shared location of read/write resources within clustered environment

Question

Within a J2EE environment (happends to be WAS 6.1 but could be any application server) I need to place a XML file, which is a configuration file, so that I can read and write to it.

This needs to be available in a clustered environment so I am looking at using the class path to load the file.

I am thinking I can store this file in the EAR root, reference it in the manifest and then load and save it.

I have tried this approach by having my file in a JAR and making this available via the MANIFES and I can load the config file from the class path no problem using the following.

this.getClass().getClassLoader().getResourceAsStream("configFileName");

That loads the file that is in the JAR, which is fantastic. But if I want to edit this file, programmatically, I cannot access the JAR files location (the EAR root) it returns me an interpreted path like this:

 /usr/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/MyApp.ear/MyApp.war/TB_config.jar

That is not the correct location of the JAR the correct location is at MyApp.ear.

So the question is: how can I access and update (copy contents, create new, save, delete old) the JAR with my config file.
Or should I put the config file somewhere else? What is the standard J2EE to make files that need read/write access available to WARs on a cluster?

Thanks for reading.

Answer 1

You cannot write to an ear file, you should place the XML file in the DB as a text lob (large object).

Answer 2

The problem that you've hit is not unique. A lot of J2EE/JEE programmers can struggle with providing a "configurable" property file to administrators of a cluster. And the solution that you've chosen, well, has its limitations.

The problem with embedding a config file inside a JAR, is absolute path or the physical path of the file, in case you need to update it. If your container will not explode your EAR and WAR files, then placing the config file alongside the code is a bad idea - the administrator will have to deploy a newer version of the EAR/WAR/JAR. That is unless, of course, you can configure the container to explode the artifacts - WebLogic Server does this, I'm not sure about WAS.

There are several ways to resolve this problem:

• Store the config file in a SAN that is accessible to all the nodes in the cluster via a 'canonical' path. That way, you could locate the file from any node in the cluster and update it. Remind yourself to restrict access to this directory. Although this sounds simple, it need not be - Java objects might have to be 'flushed' across nodes, once the configuration file has been updated. Moreover, you might have to cater to the scenario where property files can get edited outside the application.
• Use a database. Much simpler and almost hasslefree, except that the Java objects might have to be flushed again.
• Use a MBean. As good as a database, except that I haven't known a lot of people vouching for the MBean support in WAS. Also, I'm not really sure if object states can go haywire across a cluster, in this case.

Answer 3

Actually, as I am using WebSphere, it appears I can use the dynamic cache provided by the WebSphere deployment manager. The last chapter in the link below dicusses the use of the Dynamic Cache providing a shared object in a cluster. The configuration file is XML that is parsed as such by the engine (into a Document object) of the application and so is a Java object, thus it can be placed into the DistributedMap.

Looks like a clean solution. Thanks all for reading and your replies.

http://www.ibm.com/developerworks/websphere/library/techarticles/0606_zhou/0606_zhou.html