WebSphere and PropertyPlaceholderConfigurer

Question

Hi,

I'm a big user of properties (with PropertyPlaceholderConfigurer) for making my application as "dynamic" as possible. Almost all the constants are defined as such. Anyway, I'm currently defining a default.properties which comes shipped with the default WAR.

In other environments (Acceptance/Production) I need to overwrite of the configurations. I'm doing this as following:

<bean id="propertyManager"
     class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
     <property name="locations">
      <list>
       <value>classpath:com/company/default.properties</value>
       <value>file:${COMPANY_PROPERTIES_LOCATION}\kbo-select-settings.properties</value>
      </list>
     </property>
    </bean>

With this means I can use a promotable build for each of the environments.

HOWEVER, I do dislike the fact that I can't change any of my properties from inside WebSphere. Instead I have to go to each of the servers (we have 8 clustered) and change the properties accordingly. It would be a lot more user friendly if I could change those from inside WebSphere and just perform a restart afterwards...

Anyone has an idea on how I could do such a promotable build? I already define JNDI configuration for datasources/java mail/etc.

Thanks!

Answer 1

If the configuration is in the EAR file then I know of no simple way to propogate changes without backdoor cheats or re-deploying the app.

I think that configuration, espcially that which changes when you promote the app should not be in the application.

One approach is described here by Keys Botzum,

Note that you can actually propogate files that are not part of any particular application out to nodes using standard WebSphere synchronisation.

Another option is to use a database for config. These days poppin XML into a DB such as DB2 is not very hard.

Answer 2

We solved this problem by using an extension on the property file for each environment (local, dev, int, tst ...) and each file contained specific values for those environments. The only addition you then require is a VM argument on the server to set -Druntime.env=X.

Your lookups in your config file will then look like this

<bean id="propertyManager"
 class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
       <list>
          <value>classpath:com/company/default.properties.${runtime.env}</value>
          <value>file:${COMPANY_PROPERTIES_LOCATION}\kbo-select-settings.properties</value>
        </list>
    </property>
 </bean>

Of course this only works if you have fairly static environments, as it still doesn't lend itself to changing it at runtime, but it does makes promotion of the application dead simple. If you want to be able to change the values without redeploying your application, you will have to have them stored outside your application, which you already seem to be doing for the kbo-select-settings.properties

Answer 3

Adding a URL resource that points to your config files to your websphere servers and then looking that up in your application is a viable way to go. You can then configure the url to point to a central location where all the configuration files are managed - if you use svn and your svn has read-only access you could even directly read them from svn (via http).

Spring has some built in facilities for this, and it also means you can priorities various config files.

For more information take a look at how-to-differentiate-between-test-and-production-properties-in-an-application

Answer 4

The way that I have dealt with this is to use property values on the JVM's but then reference them to a WebSphere variable that is defined at the cluser or cell level. For example, say you want a value called value1 set in param1 in your spring configuration you would do the following:

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" />

And then something like as follows do reference the variable:

<bean id="id" class="com.blah.class">
        <property name="value1" value="${param1}" />
</bean>

Then within your tests you can setup your tests as follows:

/**
     * @see org.springframework.test.AbstractSingleSpringContextTests#prepareApplicationContext(org.springframework.context.support.GenericApplicationContext)
     */
    @Override
    protected void prepareApplicationContext(GenericApplicationContext context) {
     System.setProperty("param1", "myvalue");
        }

Then from within the websphere configuration, if you create a JVM variable and link it to the WebSphere variable you only need to change the WebSphere variable and it will automatically update all the JVM variables on each machine.

To do this, create a JVM variable called:

param1

with a value of ${webspherevar.param1}

And then create a WebSphere variable called:

webspherevar.param1

That contains whatever the value you need to put in it. This allows you to then not have to ship around the values for each environment and they can be instead loaded into the environment and just used.

I hope this helps.

Answer 5

One potential issue is that you are hardcoding the location of your properties file. You could specify the location of the properties file as a JNDI resource and falling back on the defaults specified on the classpath:

<!--  try to lookup the configuration from a URL, if that doesn't work, fall back to the properties on the classpath -->
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="location">
     <bean class="org.springframework.core.io.UrlResource">
      <constructor-arg>
       <jee:jndi-lookup 
        jndi-name="url/config" 
        default-value="file:///tmp" /> <!--  dummy default value ensures that the URL lookup doesn't fall over if the JNDI resource isn't defined -->
      </constructor-arg>
     </bean>
    </property>
    <property name="properties">
     <bean class="org.springframework.beans.factory.config.PropertiesFactoryBean">
   <property name="locations">
    <list>
     <value>classpath:com/company/default.properties</value>
    </list>
   </property>
  </bean>
    </property>
    <property name="ignoreResourceNotFound" value="true"/> 
</bean>

That way you can specify different file names for different environments using the WAS console in Resources > URL > URLs by creating a resource with the JNDI-name "url/config" and pointing it to the correct file (file:///your/path/to/properties).

As an alternative solution, if you want to manage individual properties through the console, you instead of using the PropertyPlaceholderConfigurer you could use jee:jndi-lookup to get values from the web.xml env-entries (which you can manage using the WAS console). See this answer