Creating a proprties file

[Tony Evans]

I have a webservice that resides in a weblogig . ear file. At the moment I have a number of hardcoded paths in the application that the aplication uses.

WhatI want to do is remove those hardcoded paths from the application and put in a properties file. There are many links on how to create a properties file.

But not many examples on where a properties file should reside. I do not want the properties file inside the .ear file as every time a path would change the ear file would have to be regenerated.

Is there a directory in weblogic where you can put the properties file, which the application can pick up just using the properties file name and not having to hardcode the path to the properties file.

The only hardcoded value I would ;ike is the actulal properties file name.

Thanks for any help

Tony

[SpringTiger Liu]

You can create a directory such as "properties" under your application domain, and leave your properties file in this directory.

domain/properties/anyname.properties

The system property has been set in start server command line such as:
-Dmydomain=

You can get this property by calling System.getProperty("mydomain") to get location of our properties file.

[Reid M. Pinchback]

Even easier, you could move all those hardcoded values in the Java code to env-entry elements in the deployment descriptor. If you use an exploded directory deployment, the only difference is that you edit an XML-format file instead of a properties-format file. And the file lives with your application, which is more intuitive. As bonuses you don't have to worry about deploying another application that used the same property names but with different values; you can even have different components in the same app with different values for the same "property" (= env-entry) name.

Downside: not convenient for editting if you don't use the exploded directory approach to deployment.

[Roger Chung-Wee]

A problem with environment entries is that they cannot be shared by beans from other homes - even if they are in the same app. Also, changing an entry requires a rebuild and a redeployment.

For properties files: if you don't want them in the EAR, then just place them on the server classpath. When the server starts up, the files will be available. You can then create ResourceBundles from the files.

[Reid M. Pinchback]

A problem with environment entries is that they cannot be shared by beans from other homes - even if they are in the same app. Also, changing an entry requires a rebuild and a redeployment.

Which is why said the magic words "If you use an exploded directory deployment". No rebuild. Redeploy issue is no different for env-entry than for a classloader-read property file. The classloader won't know about the properties file change until a redeploy either. The only way you avoid that is if you use file I/O to read the properties file directly, but that is an EJB no-no unless you use something like fscontext to let the container know about the potential I/O blocks and to get past any (typically only in a production environment) security manager blocking filesystem access.

Definitely true that only one bean home gets to see the env-entry. I'd put that more in the advantage column than the disadvantage. Multiple beans depending on the same properties can be a sign of poor component design or implementation. If a property is that important some other component or component method should be representing that importance.

[Roger Chung-Wee]

Ah, but Tony says that he has an EAR, so we are looking for a solution which can easily fit in with his build/deployment strategy.

I'm assuming that the hardcoded values which he refers to relate to the app rather than to a particular EJB. In such a case, I see a properties file as being a good solution.

[Jignesh Patel]

Instead of creating property file. Create a XML with all the hardcoded paths. Use XML beans to get variables from XML file.

[Roger Chung-Wee]

An XML file will work. But if you simply want key/value pairs (which is what I suspect is needed here), then XML is overkill.

[Jignesh Patel]

As far as coding for loading properies file and reading it takes more time then just using XML and xml beans for weblogic(ie. by using workshop you can create xml beans in seconds).

As far as for processing time, I don't think reading key, value pair from properties file is noticable compare to reading from xml file.

I don't see anywhere XML is overkilling?
If I am wrong I do like to know your thoughts.

[Roger Chung-Wee]

XML is quite powerful, but takes more effort to design/write. Nothing is simpler and easier to write and to maintain than a properties file for simple key/value processing.

Here's an analogy: Using XML in this scenario is like buying a turbocharged 4WD vehicle to do your shopping around town. Why would you want an over-engineered solution?