System configuration per environment

[F.Degenaar]

@Kristina:
Just put the properties files for all stages into your archive. There will probably be items your admins don't want you to know like production passwords. For those items you can still define resource environment entries in your web.xml or ejb-jar.xml. Your admins can configure them in the app server's JNDI tree.

HTH
Fokko

[Kristina]

Hello Chris,

thanks, this works great!
But the properties files are still in the war archive.
I am wondering if it's possible to place the properties files somewhere on the server file system and access them there?
That would be even better...

[Chris Lee]

Since the code use a Resource object, you can inject the location using the classpath: or file: prefixes.

For example, to have the properties files in '/opt/app/conf':

<property name=""propertyLocation" value="file:/opt/app/conf/"/>

...note that the trailing slash is required to denote this as a directory so the properties files can be found relative to the directory.

[jstehler]

I use the JNDI approach. I bound a java.util.Properties object into our app server's JNDI tree, configuring it from a properties file located outside of the war file. The specifics on how to do this depend on your application server.

For different environments, you'd just use a different properties file. The JNDI object is configured and bound at app-server startup.

This properties JNDI object can be accessed by your app directly via JNDI, or given to a PropertyPlaceHolderConfigurer like so:

  <bean id="propertyResourceConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="properties"><ref local="config" /></property>
  </bean>
  <bean id="config" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName"><value>config/Properties</value></property>
    <property name="resourceRef"><value>true</value></property>
  </bean>

where "config/Properties" is the JNDI name defined in web.xml and mapped in the appserver-specific web xml file.

Then you can configure your beans by using ${property} throughout your application context as mentioned by other posters.


Tim

I like this idea, and you could take it one step further, by defining a local properties object as the 'defaultObject' property of the JndiObjectFactoryBean. This way, if the JNDI environment is unavailable as it would be in a unit test or local non-server environment, it will fall back to localized settings.

[Kristina]

For loading the properties file is the solution with RuntimeEnvironmentPropertiesConfigurer more fliexible than with JNDI.
you can put your file anywhere and don't need to configure the JNDI on the appserver.

thanks!

[antony.stubbs]

I have a similar desire - I posted about it here: http://forum.springframework.org/showthread.php?t=46504
"Conditional importing/loading of alternate beans.xml - environment specific beans"

Basically I want to conditionally instantiate my JNDI beans dependant on environment - basically in test there's no JNDI. You can use <import> tags with ${} system properties, *but* I want it to default to a default import if the system property is not set.

[cfieber]

I've used a similar approach, but with a set of layered properties files, typically:

common.properties -- generally stuff in here is common across all deployments
${environment}.properties -- dev, test, staging, production
${instance}.properties -- stuff specific to the unique deployed instance, if needed

each file can override the ones above. I found this leads to easier configuration maintenance because a good deal of the stuff extracted into property configuration doesn't actually have to change among environments

also, I try to avoid using properties to specify bean references or bean classes, as I've found that leads to pretty fragile configuration

[antony.stubbs]

I've used a similar approach, but with a set of layered properties files, typically:

common.properties -- generally stuff in here is common across all deployments
${environment}.properties -- dev, test, staging, production
${instance}.properties -- stuff specific to the unique deployed instance, if needed

each file can override the ones above. I found this leads to easier configuration maintenance because a good deal of the stuff extracted into property configuration doesn't actually have to change among environments

also, I try to avoid using properties to specify bean references or bean classes, as I've found that leads to pretty fragile configuration

This doesn't address my need to conditional instantiation of beans. I need to not instantiate a bean in one environment, and instantiate in another. It's can't be seperated into properties. (it's a bean looked up from jndi where JNDI doesn't exist in one of the environments i.e. jetty (i know you can setup jndi with jetty, but i don't want to have to)).

[clint.shank]

I've just posted an alternative approach, where all properties are contained in a single properties file here.

[jeff_johnston]

I started a project that you may be interested in. It is called Configleon and solves the problem of loading property attributes in different environments and/or server contexts. With Configleon you can build one war file that can be deployed to every location.

Configleon really shines is in its ability to cascade the property attributes. This allows all the common attributes to be defined in a global file and then overridden for each application server context.

http://code.google.com/p/configleon/