Best place to put a properties file in IBM websphere 8.5?

Question

The jar file is embedded in our existing application properties file, we decided to transfer the properties file outside the ear (application), what is the best place to place the properties file in IBM websphere 8.5? so that I can get the path with the WAS Environment variables, and the file should be accessible to all nodes in the cluster.

Answer 1

You can use classloader directories for this. I would use the directory classes (maybe you need to create) under the classes $ WEBSPHERE_HOME / AppServer / and drop them. You should be able to find them on any of your applications / servers.

Check out the classloader page .

Answer 2

Only my 2 cents in discussion.

For a quick and easy solution, I did not put the properties file in the WAS_HOME / classes, but in PROFILE_ROOT / properties - this folder is in the class path and is used to store properties anyway. One advantage over classes is profile coverage, so if you have different profiles, for example, for testing or integration, they can have different settings.

And for a “clean” WebSphere solution that allows you to manage properties through the console, you could check out the resource providers (but a rather long and complicated solution): http://www.ibm.com/developerworks/websphere/library/techarticles/0611_totapally/0611_totapally .html

Answer 3

Unlike the (currently) accepted answer, I argue that placing something under WAS_HOME/classes is a laid-back practice. This directory is often used by IBM to host class / JAR files that are considered "internal" to WAS and related products (for example, certain versions of WebSphere Portal place JAR files in this directory).

In addition, placing elements in WAS_HOME/classes makes the elements available to all applications running on all WAS profiles created from this WAS installation. You cannot change this behavior; that how was designed. This is another reason to conclude that WAS_HOME/classes should be reserved for internal use of WAS.

This argument can be generalized almost anywhere in WAS_HOME : user files (that is, files not provided by the software vendor) should not be located in places controlled by the product installer / uninstaller. The WAS_HOME hierarchy WAS_HOME managed by IBM Installation Manager (or the WAS installer, depending on the version of WAS). I would by no means put any of my files.

Now back to your question. If you must have your property files “free” (that is, not included in any particular EAR), the best thing to do is:

• Create a directory outside the WAS directory tree and place your files there.
• In WAS, create a shared library definition.
• Add the directory created to the shared library.

• Attach the shared library to the server or to the applications to which you want your property files to be accessible:

  • To attach a shared library to the server, create a new Classloader on the server and attach the shared library to it.
  • To attach a shared library to an application, make an attachment by editing the EAR properties in the administration console or by using deployment option scripts.

Answer 4

try it

• Create a directory (location of your choice) to save the properties file.
• Add the directory to WebSphere CLASSPATH.
• Download the properties file from CLASSPATH.

Answer 5

another solution I'm using is to add a URL resource link to your web.xml application. For example, "url / properties".

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

Then, during deployment, map the URL link to the corresponding web page URL definition.

Now your code can simply search the jndi url.

This has the advantage that you can deploy a single code base and configure the deployment time to point to different URLs.

Answer 6

A database is the best place to place properties if property values ​​are not specific to a single node in the cluster and the property value is a password. For properties such as passwords, I suggest you set the property values ​​as jndi properties in WAS. Use the general configuration to read from both sources. Have a .property file in your code base that will override values ​​from both db and jndi. This way, your developers can override the db / jndi values ​​during the development process.