Spring 3.1 @Profile and @PropertySource

Today, I'd like to go over a cool new feature that the good folks at Spring are releasing as part of Spring 3.1...Profiles.

I won't go into too much detail about how profiles work because SpringSource's Chris Beams has already done a good job of that already -> Read about it here

Instead, I'd like to take on a very simple use case where this feature will be VERY helpful. Most developers have run into a scenario where they needed to bootstrap their application with beans that are slightly different based on the environment. For example, a datasource might be different for dev, test and prod. With the help of Spring @Profile and the @Configuration classes, this is a complete snap to do now. Let's dive into the example.

My project has two beans: CommonBean which is the same for all environments, and EnvBean which has environment specific configuration (in the real world, EnvBean could be a datasource, jms connectivity beans, etc..). The last wrinkle to this app is that my EnvBean requires environment specific properties as well. A very simple use-case, but complete enough to demo the new capabilities.

Here's the source for my application beans:

You see they are simple Java POJOs. Now, I create a per environment properties file for dev, test and prod with the properties, I am calling them -app.properties.

Now here's where @Profile comes into the picture. To distinguish the various environments, I create a common @Configuration class called AppBootstrap and a per environment @Configuration class to configure the EnvBean.

That's it. Now my app is configured to have a different configuration PER environment. So I can run a test to prove this out:

Voila! With each run*Example() test you will notice that the appropriate @Profile was invoked and the environment specific properties file was used to configure my EnvBean.

Pretty slick new feature from the guys at Spring! Did I mention, this whole thing was done with NO SPRING XML!!!

If you want the source for this, you can grab it from Bitbucket => click here

More to come and as always, I hope this helps! Cheers!

Maven 3 Polyglot Support

A while back I wrote a post where I created a little demo which used Groovy, Maven, JPA and Hibernate. The code is here.

I was taking a look at the Maven 3's new polyglot POM support and decided to convert that application's build to use the Groovy DSL. If you take a look at the Maven 3 Polyglot code, you will notice it is simply converting the Groovy DSL into the same POM object that would be created with the XML config. Still, it does make the configuration much more terse. Compared to the pom.xml, the pom.groovy is less than half as many lines. Moreover it just seems to be a bit cleaner and flows nicely.

For example, where we would have declared a dependency in the pom.xml as:

You can do the same thing in the Groovy DSL as:


Before getting too excited about this new Polyglot support, there are a few cons. First, and perhaps a deal breaker for some would be tooling support. Eclipse doesn't support this form of configuration, so you'd have to use Maven eclipse .project/.classpath plugin in order to develop in Eclipse....yet another reason to code in Textmate ;P

Second, as I said before, the DSL really only converts the config into the same POM object as the XML version would. You can't write executable Groovy code in the DSL unless you use the gmaven plugin. That's sort of a bummer.

The DSL is nice and makes configuring a Maven project MUCH cleaner. I will most likely use it for Maven projects in the future. I have also heard great things about Gradle, and will take a look at that build tool next.

In the meantime, if you want the code with the Polyglot Maven build, here's the link.