Spring 3 java config and Maven

[skal111]

I'm a big fan of Spring 3's Java config integration and I've been using it to load my beans, inject variables from properties files etc.

Prior to Spring 3 I used xml configuration files where I would declare property-placeholder files. These properties were then injected by Spring using the ${xxxx} syntax.

<context:property-placeholder location="classpath*:config/*.properties" />

<bean id="myBean" class="com.example.MyClass">
	<property name="myProperty" value="${dummy.property.value}" />
</bean>

While using Maven's profiles I was able to substitute these ${xxx} properties with real values coming from specific files. I had 3 profiles : dev, test and production therefore I could build war files for these 3 environments with a single command line.


Is there such a way to do so and enable Maven properties injection with the Spring 3 java config syntax. Per example how could I inject different values for the following code for different environments?

@Value("#{properties.myProperty}")
private String myProperty;

@Bean
public MyClass myClass()
{
	MyClass myClass = new MyClass();
	myClass.setMyProperty(this.myProperty);

	return myClass;
}

Maven will not introspect through source code and will not be able to hot replace those properties values from a given file. Is there another way to do so?

[Marten Deinum]

Why... Why use maven to replace the placeholders, that basically beats the purpose of the PropertyPlaceHolderConfigurer. The PropertyPlaceHolder should do such a thing and with that you should (and could) build one 1 war deployable in ALL your environments. Just include the properties file on a well known location.

So instead of relying on maven to replace the placeholders, rely on spring and that way it also works with code if you use the @Value annotation.

[skal111]

I'm sorry but I don't quite follow you there. How can 1 war file be deployed to all my environments with different config (DB schema...).

Can you be more specific.

Thanks for your help

[Marten Deinum]

That is what the PropertyPlaceHolder does for you. The propertyplaceholder inspects your configuration at RUNTIME for ${} and replaces the properties accordingly. So instead of relying on maven to replace thos ${} at BUILD time, let spring do it for you RUNTIME.

my.properties

# Dev properties
db.schema=devschema
db.user=user
db.password=pwd

my.properties

db.schema=prodschema
db.user=secret-production-user
db.password=secret-production-password

Simply drop them in the location you specified (user.home, some general available config directory) and spring will read the my.properties file and replace the ${} at RUNTIME and because spring does it it replaces the ${} anywhere, xml or code.

[skal111]

OK I see what you mean but that is not an option to me. Indeed it implies, as you say, that there is a general available configuration location on all of my environments : user home is a good example.

But that means I have to MANUALLY deploy different versions of my properties files to each of the environments. The purpose here is to have all the resources embedded within the WAR file so it is ready to be used as is.

[Marten Deinum]

Which also puts the burden of managing and deploying the application to different locations. Normally that is not the case, also in general that means that you build a different war for dev/test/accept/production which in theory should also mean everything needs to be tested 4 times. 4 build cycles resulting in different wars. (It is more or less a dicussion about theory but I have been working on multiple projects where this was the rule, new war/artifact means testing eveyrthing).

However even if you read the properties files from within the war the PropertyPlaceHolder does it work and you still dont need or shouldn't use maven to replace the ${} in your configuration. As I stated earlier let spring do that for you and that way it works regardless of your environment.