best place to put properties file in IBM websphere 8.5?

Question

In our existing application properties file is embedded in a jar file ,we decided to move properties file outside of ear(application) , what is the best place to put propert

Answer 1

You can use the classloader directories for that. I would use the directory classes (you might need to create) under $WEBSPHERE_HOME/AppServer/classes and drop your properties there. You should than be able to find them from any of your applications / servers.

Check the Class loaders page.

Answer 2

Just my 2 cents in the discussion.

For quick and easy solution I'd put the property file not to the WAS_HOME/classes but to the PROFILE_ROOT/properties - this folder is on the classpath, and its used to store properties anyway. The one benefit over /classes is that is scoped to profile, so if you have different profiles for example for test or integration they may have different settings.

And for 'pure' WebSphere solution, that would allow managing properties via console you could check out the resource environment providers (but its rather long, complicated solution): http://www.ibm.com/developerworks/websphere/library/techarticles/0611_totapally/0611_totapally.html

Answer 3

Database is the best place to put the properties if the property values are not specific to one node of the cluster or the property value is a password. For properties like passwords I would suggest you set up the property values as jndi properties in the WAS. Use commons configuration to read from both the sources. Have a .property file in your codebase that will override the values from both db and jndi. That way your developers can override the db/jndi values in development.

Answer 4

try this

1. Create a directory (location of your choosing) to hold the properties file.
2. Add the directory to the WebSphere CLASSPATH.
3. Load the properties file from the CLASSPATH.

Answer 5

another solution, which I use, is to add a URL resource reference to your application web.xml. For instance "url/properties".

Then define URLs in Websphere, using the admin console, to point to "file:///dev.properties", or "file:///test.properties", for example.

Then at deploy time, map the URL reference to the appropriate websphere URL definition.

Now, your code can just do a jndi lookup of the URL.

This has the advantage that you can deploy a single codebase, and customise at deploy time to point to different URLs.

Answer 6

Contrary to the (currently) accepted answer, I argue that placing anything under WAS_HOME/classes is a discouraged practice. This directory is often used by IBM to place classes/JAR files that are considered "internal" to WAS and related products (for instance, certain versions of WebSphere Portal place JAR files in that directory).

Also, placing items in WAS_HOME/classes makes the items available to all applications running on all WAS profiles created off this WAS installation. You can't change that behaviour; that's how WAS is designed. That's another reason to conclude that WAS_HOME/classes should be reserved for WAS internal use.

This argument can be generalized to practically any location under WAS_HOME: user files (that is, files not provided by the software vendor) should not reside in locations that are managed by the product's installer/uninstaller. The WAS_HOME hierarchy is managed by IBM Installation Manager (or the WAS Installer, depending on the WAS version in question). I wouldn't put any of my files anywhere there.

Now, back to your question. If you must have your property files "loose" (that is, not included with any particular EAR), your best bet is to do the following:

1. Create a directory outside the WAS directory tree and place your files there.
2. In WAS, create a Shared Library definition.
3. Add the directory you created to the Shared Library.

4. Attach the Shared Library to either the server or the application(s) you'd like your property files to be available to:

   • To attach the Shared Library to the server, create a new Classloader element on the server and attach the shared library to it.
   • To attach the Shared Library to the application, perform the attachment through editing the EAR's properties in the administration console, or through scripted deployment parameters.