Introduction to Spring profiles

So many men, so many minds. When we are implementing software for different customers we sometimes need to handle various requirements for the same project. For example Customer A needs SAML authentication and customer B needs LDAP authentication.

With Spring Profiles (available from Spring 3.1) we are able to provide a way to segregate parts of our implemented application configuration. This blog will help us to make certain code or rather certain Spring beans only available for specific requirements. For example the example used in this blog can be used to activate the required authentication provider for the provider manager when using Spring Security.

Profiles can be configured by annotations and/or by xml.

Annotations
@Component or @Configuration annotated beans can contain the annotation @Profile to only load them in a certain environment.

XML
Probably not used anymore in freshly started projects, but it is also possible to make certain Spring beans only available within your XML configuration.

Activate correct profile
Of course you are able to combine both configurations, but is should be obvious to choose one configuration to make your code more predictable . Just to show the possibilities we have combined them in one project.In a plain Java application the profiles can be setup by activating the profile in your application context.

See the following github for the full source of this project:
https://github.com/michelmeeuwissen/Spring-Profiles-Intro

 

Grails Goodness: Conditionally Load Beans in Java Configuration Based on Grails Environment

In a previous post we saw that we can use Spring’s Java configuration feature to load beans in our Grails application. We can use the @Profile annotation to conditionally load beans based on the currently active Spring profile. We can for example use the Java system property spring.profiles.active when we start the Grails application to make a profile active. But wouldn’t it be nice if we could use the Grails environment setting to conditionally load beans from a Java configuration? As it turns out Grails already set the current Grails environment name as the active profile for the Grails application. So we can simply use @Profile in our configuration or component classes, like in a non-Grails Spring application.

Continue reading

Grails Goodness: Use Spring Java Configuration

A Grails application uses Spring under the hood, which means we can also use all of Spring’s features in a Grails application. For example we can use the Spring Java configuration feature with our Grails application. The Java configuration feature allows us to write a Java or Groovy class to define beans for our application. Of course in Grails we have the nice bean builder syntax when we define beans in the grails-app/conf/spring/resources.groovy file, but maybe we must include a Java configuration from an external library or we just want to write a configuration class ourselves.

This post is very much inspired by this blog post by Andres Steingress.

Continue reading

Grails Goodness: Set Property Values of Spring Beans in resources.groovy

We can configure Spring beans using several methods in Grails. We can for example add them to grails-app/conf/spring/resources.xml using Spring’s XML syntax. But we can also use a more Groovy way with grails-app/conf/spring/resources.groovy. We can use a DSL to define or configure Spring beans that we want to use in our Grails application. Grails uses BeanBuilder to parse the DSL and populate the Spring application context.

To define a bean we use the following syntax beanName(BeanClass). If we want to set a property value for the bean we use a closure and in the closure we set the property values. Let’s first create a simple class we want to configure in the Spring application context:


Next we configure the bean in resources.groovy:


There is also an alternative syntax using Groovy’s support for named method arguments. In Groovy named arguments are all grouped into a Map object and passed as the first argument. The BeanBuilder DSL supports this feature. When we define a bean we can use named arguments for the property names and values, use the BeanClass argument and automatically this will be converted to Map and BeanClass type arguments.


Written with Grails 2.2.1

Original article

Keynote SpringOne 2GX

Juergen Hoeller
Hoeller begint zijn presentatie met de originele driehoek van spring. Zijn verhaal beschrijft vervolgens de transitie die het framework heeft gemaakt sinds dat model naar een annotation framework. Hij legt de nadruk vooral ook bij de beschrijvende namen van de annotaties, en hoe ze zorgvuldig zijn gekozen om de code leesbaarder te maken.

Hierbij gaat hij dieper in op een aantalannotaties zoals stereotypes, injections en ook parameter annotaties. Hierbij geeft hij aan het gevoel te hebben dat de kracht van deze annotaties nog steeds wel onderschat wordt.

Continue reading

Spring Tip: Check for existence of Bean during startup

Sometimes we are working on an application where we have no control over specific Spring bean implementations. Nevertheless we want to check for the existence (or duplication) of these bean implementations during start-up of the application server. Since Spring version 3.0 it is possible to use Spring’s ApplicationListener. This interface is based on the EventListener and uses the standard Observer design pattern.

In 3 steps we can easily check for the existence of a specific Spring bean.
Continue reading

To Roo or not to Roo…

Recently I’ve been looking into Spring Roo to find ways to speed-up software development as well as reducing plumbing code.
In this blog post I will highlight some of the advantages and disadvantages of Spring Roo which I stumbled upon. So don’t expect a full featured introduction or tutorial; plenty of those already exist on the internet ;-)

A unique approach on code completion
Spring Roo takes on a different approach to code generation compared to other solutions.
Instead of generating additional .java files (through the “Generation Gap Pattern”) it generates so-called AspectJ inter-type declaration (ITD) .aj source files.
Each generated inter-type declaration (ITD) type will “weave in” structural changes to its target .java file; for example to add new methods (i.e. getter/setter methods) or an “implements …” clause.

Continue reading