Benedict Fernandes and Keys Botzum have provided an article on developerWorks on Using URL resources to manage property files. For many teams this may be the right solution.
A colleague and I had a conversation about this recently as he was getting ready to lead another team through some portal development. For me it often depends upon how I am involved in a project as to where I put the file. What is really troublesome however is large projects with many portlets and many developers who are stepping all over each other in their property usage. Sometimes this happens when several portlets are using the same properties, such as a database or LDAP connection.
1. Without proper communication each will probably end up setting up their own property, and when the application gets deployed, someone has to set the same property value several times.
2. Other conflicts can occur when someone tries to use a common properties file, but assumes a different meaning for a specific property. This can cause a conflict when two different components want different values for the same property.
Item 1 most people can live with, although deployment has to be better documented to ensure that the property is changed in all the right places. Item 2 is more difficult and can require a rework of the code.
During our conversation I suggested we build up a properties service that would deliver properties to the calling components and could be searched by other developers to see if a property they were considering already existed. After stumbling around a little bit I saw that J2SE 1.5 now allows you to load properties via an XML files as well as using the standard name=value pairs approach. Using XML was interesting to me because it would allow me to add meta-data right to the property itself. Only problem here WebSphere Portal has not moved up to 1.5 yet. No problem, I'll just build my own XML based property service.
I came up with a very simple format that seemed to achieve what I wanted.
<?xml version="1.0" encoding="UTF-8"?>
<desc>URL to connect to the ldap</desc>
<desc>JNDI name for connecting to MyApp database</desc>
and then the service was built as a very simple singleton around this central file.
The portlet is pretty generic. No real searching or formatting, it just lists things out one after another. I suppose the extra effort could be taken into account during other project work so this approach could build upon itself. The portlet does allow you to reload the properties file without restarting the server, which is handy.
Once a developer knows what property they want need they can access it using something like
PropService propService = PropService.getInstance();
String propValue = propService.getProperty(“propertyname”);
I've posted this sample code on my personal site Bernal.net for you to take a look at and reuse if interested. The whole thing probably took 2-3 hours, including the portlet and my stumbling at first. But the potential savings could be huge with a little more work to polish things up a bit. Of course I've posted more info at PortalPatterns.org.
As always I would love to hear your comments on how you approach properties within your organization or if you have some of the problems I have mentioned above?
For those of you that care: Hey, no rewrite rules needed![Read More]