by March 28th, 2012on
Lee Burch, one of our extremely talented architects, gave me a writeup on “Using WPS style Resource Environment Providers with Spring” He wanted to know where to post something like this and of course, my first thought is this blog. His justification for posting this is that while it’s a common use case in the WebSphere Portal world, many developers get it wrong. So thanks to Lee for the post.
Generally a problem most projects face is how to handle configuration information that varies between environments. Many times you can handle this by using one of WAS built in resources such as a SMTP server or a JDBC connection pool. However many times the configuration data won’t fit one of these existing WAS resource types, such as an e-mail address, a server name or a URL. To solve this a lot of approaches are available some use build tools such as Maven to build different EAR files, others use properties files located outside of the EAR. Unfortunately both of these solutions have their issues and can be difficult to manage.
To solve this problem WAS provides and WPS leverages the resource environment providers. These allow you to specify your settings as a part of the WAS console at the Cell, Node or Server level. This provides an easy way to maintain values across many servers while also doing away with the need to have special EARs built for each environment.
The following IBM article discusses this
Unfortunately it requires deployment to the App Server lib/ext directory, something that is not always so easily done particularly in a shared enterprise environment.
However WPS uses Resource Environment Providers but does so differently than the above article specifies, it uses the “Custom Properties” of the resource environment provider and requires no deployment to the App Server, an ideal solution.
While it is possible to bind your code directly to the fetches to the Resource Environment Provider I find a more flexible and much more modern way of addressing the problem is to use Spring and its facility for PropertyPlaceholderConfigurer.
This allows for a Spring config something like this