9

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 properties file in IBM websphere 8.5 ? so that i can retrieve path with WAS Environment variables and file should be available to all nodes in a cluster ..

invariant
  • 8,758
  • 9
  • 47
  • 61

6 Answers6

9

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

Gas
  • 17,601
  • 4
  • 46
  • 93
  • I added a new property file in the PROFILE_ROOT/properties directory but when my application searches for the file, I receive a FileNotFound exception. On the other hand, the application can find existing property files. Do I need to perform any action for the new file to be recognized? – user12222 Apr 01 '15 at 17:09
  • @SreeramJayan Do you use `getResourceAsStream()` method to get input stream? How are you trying to load properties? – Gas Apr 01 '15 at 18:51
  • I load the properties file using FileInputStream. – user12222 Apr 01 '15 at 19:12
  • @SreeramJayan This is the reason :-). Because that folder is not on the 'file path' but on classpath. You will need to replace your method with `getResourceAsStream()` from ServletContext or ClassLoader depending on your need. – Gas Apr 01 '15 at 19:26
  • But how is that I can load other property files within the same directory with FileInputStream? – user12222 Apr 01 '15 at 20:34
  • @SreeramJayan There is no magic there, if you can load other property files from the same directory, then you either have error in the path / file name or don't have right to read the file (especially possible on Linux). – Gas Apr 01 '15 at 22:16
7

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.
Isaac
  • 16,458
  • 5
  • 57
  • 81
  • Downvoter: care to explain what's wrong with my answer? – Isaac May 26 '14 at 05:05
  • Hi, sorry. I didn't explain because I was on cellphone at that time. I downvoted your answer for a few reasons. – groo May 26 '14 at 19:52
  • I downvoted your answer for a few reasons. 1) He was very specific on his question asking a solution that should be available to all nodes in a cluster. 2) He didn't mention anything about WAS portal or other products so your point on this directory being used by other products is just worring about things that might never happen(most cases). 3) The shared library solution is much more complex and subject to errors in this case(it's valid for sure if you just want a single app. to have access to properties instead the full cluster). – groo May 26 '14 at 19:58
  • I respect your kind of approach but I might say I am the kind of guy that favors simplicity over trying to be totally compliant and perfect in solutions. aka - I favor easy of use and clarity of coding over performance until the point performance bacames an issue. – groo May 26 '14 at 20:03
  • @Isaac thanks for your answer , if putting in classes folder is problem only in portal server ..,i still feel current accepted answer is easy than shared libraries as i am not using any portal server.. – invariant May 27 '14 at 06:26
  • @invariant no problem. To each their own! (By the way: WebSphere Portal was just an example.) – Isaac May 27 '14 at 06:29
2

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.

Greycon
  • 793
  • 6
  • 19
  • I prefer best practice pattern for application configuration. More can be found at https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/ujtc_rurlsi.html – Ben Asmussen Sep 14 '20 at 15:12
  • @BenAsmussen Hi, can you elaborate? I had a look at the link you provided and it's pretty much what I described? Maybe I didn't describe it very well :-( – Greycon Sep 14 '20 at 16:26
  • Your explanations are correct, but the way of configuration is not quite clear from your post. Hence the link and the note that IBM offers a URL location loading. :-) – Ben Asmussen Sep 14 '20 at 17:25
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.

groo
  • 4,213
  • 6
  • 45
  • 69
  • You may wish to read my answer for arguments why placing items in `WAS_HOME/classes` is discouraged. – Isaac May 25 '14 at 03:16
  • I don't agree with your arguments in this case. If he had ask about how to externalize a properties for a specific application than I would have used shared libraries as you mentioned in your answer. But he was very specific asking an option to make the properties available on all nodes in the cluster. – groo May 26 '14 at 19:51
  • Still won't help. For horizontal clustering, you'd have to do this on each and every physical node anyway. The AppServer/classes approach doesn't save work; it introduces more limitations than benefits. – Isaac May 26 '14 at 20:25
  • @Isaac - I still think it's much easier, practical, less subject to human errors and better, in this specific case(for all servers in a cluster), than having to configure shared libraries in all applications. Also the shared library has the exactly same problem in horizontal clutering(you'd have to do that in all physical nodes + applications). – groo May 26 '14 at 20:33
1

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.
DwB
  • 37,124
  • 11
  • 56
  • 82
0

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.

Isaac
  • 16,458
  • 5
  • 57
  • 81
user3669895
  • 1