All 1 entries tagged Springframework
No other Warwick Blogs use the tag Springframework on entries | View entries tagged Springframework at Technorati | There are no images tagged Springframework on this blog
September 02, 2005
I recently had to generalise some configuration I had for Single Sign On (SSO). Some configuration which I didn't think was going to change on a per server/deploy basis, does indeed need to change. Generally we don't like to do a different build per different server so we try to put settings that will change on a per server basis into external configuration.
Traditionally this is done via system properties (System.setProperty("sso.someproperty","true");) which we set in the properties-service.xml file in the JBoss deploy directory. These are really handy as they are dynamically reloaded every time you change them so you can quickly change something at run time. We use this for hot changing where web services point at for instance in case one breaks.
However, there are sometimes bigger configuration changes that you might want to make which are not really just single strings. Not only that, the system properties don't really fit in very well with a Spring way of thinking.
Spring offers two possibilities. From their documentation they talk about the PropertyPlaceholderConfigurer but that just puts individual string properties in an external properties file again.
I decided just to split out the parts of my XML bean configuration that are per server specific into separate file. You can then just dump a smaller configuration file somewhere in your classpath (such as the JBoss conf directory) that is per server specific. In your web.xml you can reference your configuration like this:
<context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/main-spring-beans.xml,classpath:deploy-specific-beans.xml</param-value> </context-param>
And there you go, you have a nice Spring XML configuration to put your server specific configuration in, without a separate build.