Introduction to Spring profiles

Posted on March 10, 2015 by Michel Meeuwissen

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.

@Component
@Profile("ldap")
public class LDAPAuthentication {	
   public LDAPAuthentication() {
      System.out.println("LDAP Authentication set by annotations");
   }	
}

@Component

@Profile("ldap")

public class LDAPAuthentication {

public LDAPAuthentication() {

System.out.println("LDAP Authentication set by annotations");

}

@Component
@Profile("saml")
public class SAMLAuthentication { 
   public SAMLAuthentication() {
      System.out.println("SAML Authentication set by annotations");
   } 
}

@Component

@Profile("saml")

public class SAMLAuthentication {

public SAMLAuthentication() {

System.out.println("SAML Authentication set by annotations");

}

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.

<!--    
   We use the profile attribute on the beans element to specify the profile.
   Only the child beans are loaded on initialization if the profile is active 
-->
<beans profile="ldap">
   <bean class="com.jdriven.blog.profiles.xml.LDAPAuthentication" />
</beans>
<beans profile="saml">
   <bean class="com.jdriven.blog.profiles.xml.SAMLAuthentication" />    
</beans>

<!--

We use the profile attribute on the beans element to specify the profile.

Only the child beans are loaded on initialization if the profile is active

-->

</beans>

</beans>

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.

public static void main(String[] args) {
   //Create new context to show the XML Spring profile setup
   GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
   //Setting 'ldap' as active profile
   ctx.getEnvironment().setActiveProfiles("ldap");
   //Load the app-context.xml from the root of the classpath
   ctx.load("classpath:app-context.xml");
   //We need to refresh the application because we added a resource
   ctx.refresh();
   //Closing the application context to release and destroy all resources and cached beans
   ctx.close();

   //Creating a new context to show the annotation Spring profile setup
   AnnotationConfigApplicationContext actx = new AnnotationConfigApplicationContext();
   //Setting 'saml' as active profile
   actx.getEnvironment().setActiveProfiles("saml");
   //Scan base package for annotations
   actx.scan("com.jdriven.blog");
   //We need to refresh the application because we added a scan
   actx.refresh();
   //Closing the application context to release and destroy all resources and cached beans
   actx.close();
}

public static void main(String[] args) {

//Create new context to show the XML Spring profile setup

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();

//Setting 'ldap' as active profile

ctx.getEnvironment().setActiveProfiles("ldap");

//Load the app-context.xml from the root of the classpath

ctx.load("classpath:app-context.xml");

//We need to refresh the application because we added a resource

ctx.refresh();

//Closing the application context to release and destroy all resources and cached beans

ctx.close();

//Creating a new context to show the annotation Spring profile setup

AnnotationConfigApplicationContext actx = new AnnotationConfigApplicationContext();

//Setting 'saml' as active profile

actx.getEnvironment().setActiveProfiles("saml");

//Scan base package for annotations

actx.scan("com.jdriven.blog");

//We need to refresh the application because we added a scan

actx.refresh();

//Closing the application context to release and destroy all resources and cached beans

actx.close();

}

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

Posted on August 7, 2014 by mrhaki

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

Posted on August 6, 2014 by mrhaki

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

Posted on March 14, 2013 by mrhaki

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:

// File: src/groovy/com/mrhaki/spring/Person.groovy
package com.mrhaki.spring

import groovy.transform.ToString

@ToString
class Person {
    String name
    Date birthDate
}

// File: src/groovy/com/mrhaki/spring/Person.groovy

package com.mrhaki.spring

import groovy.transform.ToString

@ToString

class Person {

String name

Date birthDate

}

Next we configure the bean in resources.groovy:

// File: grails-app/conf/spring/resources.groovy
import com.mrhaki.spring.Person

beans = {

    mrhaki(Person) {
        name = 'mrhaki'
        birthDate = Date.parse('yyyy-MM-dd', '1973-7-9')
    }

}

// File: grails-app/conf/spring/resources.groovy

import com.mrhaki.spring.Person

beans = {

mrhaki(Person) {

name = 'mrhaki'

birthDate = Date.parse('yyyy-MM-dd', '1973-7-9')

}

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.

// File: grails-app/conf/spring/resources.groovy
import com.mrhaki.spring.Person

beans = {

    // Using named arguments to set property values. The named arguments
    // can be grouped together, but don't have to. Groovy will automatically
    // group them together into a Map and makes it the first argument of
    // the 'mrhaki() bean definition method'.
    mrhaki(name: 'mrhaki', Person, birthDate: Date.parse('yyyy-MM-dd', '1973-7-9'))

}

// File: grails-app/conf/spring/resources.groovy

import com.mrhaki.spring.Person

beans = {

// Using named arguments to set property values. The named arguments

// can be grouped together, but don't have to. Groovy will automatically

// group them together into a Map and makes it the first argument of

// the 'mrhaki() bean definition method'.

mrhaki(name: 'mrhaki', Person, birthDate: Date.parse('yyyy-MM-dd', '1973-7-9'))

}

Written with Grails 2.2.1

Original article

Keynote SpringOne 2GX

Posted on October 16, 2012 by Richard Rijnberk

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

Posted on October 4, 2012 by Willem Cheizoo

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…

Posted on September 20, 2012 by Emil van Galen

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 →