Spring autowire with qualifiers


Autowired is great annotation, which by default inject beans by type to annotated element (constructor, setter or field). But how to use it, when there is more than one bean of requested type.

Autowired with one bean

Suppose we will work with small interface:
interface IHeaderPrinter {
    String printHeader(String header)
When we have only one bean implementing IHeaderPrinter:
class HtmlHeaderPrinter implements IHeaderPrinter{
    String printHeader(String header) {
        return "<h1>$header</h1>"
then everything works great and test passes.
IHeaderPrinter headerPrinter

void shouldPrintHtmlHeader() {
    assert headerPrinter.printHeader('myTitle') == '<h1>myTitle</h1>'

Two implementations

But what will happen, if we add another implementation of IHeaderPrinter, e. g. MarkdownHeaderPrinter?
class MarkdownHeaderPrinter implements IHeaderPrinter {
    String printHeader(String header) {
        return "# $header"
Now out test with fail with exception:
Error creating bean with name 'com.blogspot.przybyszd.spring.autowire.SpringAutowireWithQualifiersApplicationTests': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.blogspot.przybyszd.spring.autowire.IHeaderPrinter com.blogspot.przybyszd.spring.autowire.SpringAutowireWithQualifiersApplicationTests.headerPrinter; nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [com.blogspot.przybyszd.spring.autowire.IHeaderPrinter] is defined: expected single matching bean but found 2: markdownHeaderPrinter,htmlHeaderPrinter
We have to decide which implementation we want to use in our test, so ...

Two implementations with Qualifier

Each bean is registered with name equal its class. For example HtmlHeaderPrinter is named htmlHeaderPrinter. The name is also its qualifier. We have to tell Autowired, that it should inject htmlHeaderPrinter:
IHeaderPrinter headerPrinter
Now our test passes again.

Two implementations qualified by field name

If field is names like implementing class (for example htmlHeaderPrinter), then this class implementation will be injected:
IHeaderPrinter htmlHeaderPrinter
And test passes:
void shouldPrintHtmlHeader() {
    assert htmlHeaderPrinter.printHeader('myTitle') == '<h1>myTitle</h1>'
Thanks to @marcinjasion.

Two implementation with Primary

We often have one implementation which we almost always want to inject, so do we still have to put Qualifier with its name wherever we want to use it? No. We could mark one implementation as Primary and this bean will be wired by default (unless we explicit give another Qualifier to use injection point):
class HtmlHeaderPrinter implements IHeaderPrinter{
    // ...
IHeaderPrinter headerPrinter


Autowired annotation allows us to inject dependencies to beans. It works great without additional configuration, when each bean could be uniquely find by type. When we have more than one bean, that could be injected, we have to use Qualifier or Primary annotation to help it find desired implementation. Source code is available here.

Spring Boot and AngularJS quick start

In this post I am going to show very simple and quick example of web application using Spring Boot with AngularJS. This app contains simple functionality of sending and storing imaginary messages. I've also used gradle for build management. All code is public and it is available on my github: https://github.com/rafalnowak/spring-boot-fun

Introduction to Spring Boot

Spring Boot is quite new project created under Spring Source umbrella. It was very few months ago when it reached version 1.0 and status of general availability.
Most important and prominent goals of this projects are:
  • providing ability to create simple web apps very quickly
  • minimizing amount of XML codebloat which is usually necessary to configure every Spring application
  • most of app configuration is automatical
  • simplify running and deployment process by using embedded Tomcat or Jetty servers that can run our applications without special effort and deploy process
  • there are lot of so called spring boot starters which are packages containing default configuration for various fields of Spring like database access by JPA, aspect oriented programming or security
As we can see, it looks promising. In this post I'll show few basic steps necessary to create and boot simple Spring Boot web application.

First steps

Although Spring Boot can be used with special command line interface tools, I've decided to use it with very popular gradle build system.
Spring Boot comes with plugins to integrate with maven or gradle. They allow us to easily run application in embedded server. Necessary instructions to include these plugin are shown on snippet below:
buildscript {
    repositories {

    dependencies {
With this basic config we can proceed to next steps. In my sample project I've divided application into two modules: one contains persistence layer with domain object and JPA repositories and another contains presentation layer with controllers. Of course this completely optional and in such simple project it does not add any benefits. But it can show how to create multi module project in gradle. Next code fragment contains common configuration for all modules in our gradle build:
allprojects {
    apply plugin: "java"

    version = '1.0-SNAPSHOT'
    group = "info.rnowak.springBootFun"

    repositories {

    dependencies {
        compile "org.springframework.boot:spring-boot-starter-test:1.0.1.RELEASE"
        compile "com.google.guava:guava:16.0.1"
        compile "com.h2database:h2:1.3.175"

        testCompile "junit:junit:4.11"
        testCompile "org.mockito:mockito-all:1.9.5"
        testCompile "org.assertj:assertj-core:1.5.0"
Now when we have common configuration, we can declare basic modules of application:
project(":persistence") {
    dependencies {
        compile "org.springframework.boot:spring-boot-starter-data-jpa:1.0.1.RELEASE"

        testCompile project(":webapp")

project(":webapp") {
    apply plugin: "spring-boot"

    dependencies {
        compile project(":persistence")
        compile "org.springframework.boot:spring-boot-starter-web:1.0.1.RELEASE"
Most important parts are including special Spring Boot Starter packages and declaring usage of spring-boot plugin in one of subprojects.
Every starter packet contains dependencies for all necessary libraries used on given feature. For example, JPA starter has Hibernate dependencies and AOP starter contains spring-aop and AspectJ libraries. What is more, with this libraries Spring Boot provides also default configuration.
It is simple quick start configuration but it is enough for some starter applications.

Let's start fun with Spring!

Our next step should be creating of starting point of application. With Spring Boot it can be done by writing regular main method in some class. Now you only need to annotate this class with special Spring Boot auto configuration annotations and application is ready to run! Example of start class is shown below:
package info.rnowak.springFun;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.annotation.ComponentScan;

public class SpringFun {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(SpringFun.class);
Well, this step look simple but it has few interesting implications for all application.
Firstly, this class enables component scan for Spring managed beans with root package info.rnowak.springFun because it is placed in this package.
Another thing is that this main method allows to run application using command gradle run. By default it uses embedded Tomcat running on port 8080. Of course this behaviour can be changed and it is very well described in project documentation. It is also possible to create runnable jar from our application.
With main class defined we can create all other classes in our application like controllers, repositories, domain classes or services. But I won't show exact examples of such classes because they do not differ in any way from the same classes in old classic Spring. If you are interesed in my example, please take a look at the repository Spring Boot Fun repo.

Add some AngularJS

One of another "side effect" of Spring Boot main configuration class is that we get few default view resolvers. View resolver, in short version, is Spring feature, which maps names of view to specific view files.
Spring Boot with its default configuration sets lookup path for index.html file which will be served by default controller. Framework looks for this file in public/, webapp/ or resources/ directory on classpath. So you can just put index.html file in one of these locations and Spring Boot will create controller serving this view. And this is the way we can use AngularJS in our project. Of course it's not the only way but it is the simplest method for using AngularJS with Spring Boot application.
In our example application index.html file was placed in webapp/ directory and it looks like this:
<!DOCTYPE html>

<html ng-app="springFun">

    <link rel="stylesheet" href="//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css">

    <script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js"></script>
    <script src="//netdna.bootstrapcdn.com/bootstrap/3.1.1/js/bootstrap.min.js"></script>

    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.0-beta.4/angular.min.js"></script>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.0-beta.4/angular-route.min.js"></script>
    <script src="js/application.js"></script>
    <script src="js/controllers.js"></script>


    <nav class="navbar navbar-default" role="navigation">
        <div class="container-fluid">
            <div class="navbar-header">
                <a class="navbar-brand" href="#/index">Spring Boot Fun</a>
            <div class="collapse navbar-collapse">
                <ul class="nav navbar-nav">
                    <li><a href="#/list">Messages list</a></li>
                    <li><a href="#/about">About</a></li>

    <div ng-view></div>

    <footer class="text-center">
        Spring Boot Fun


This file includes all angular libraries used in project, controllers definition and main application module with routing defined.
The rest of files is available in repository mentioned earlier in post so I will not provide all listings here as it would be just waste of virtual space in post :)


As we can see, Spring Boot greatly decreases time needed to write and run simple Java web application. It reduces amount of XML configuration and provieds a lot of default values and conventions. But if we want to precisely set some settings, Spring Boot does not forbid it and programmer can manually set all the settings.
Also deploy of application is simplified because Spring Boot with gradle or maven plugin allows to run application in place with these tools. We can also create runnable jar that contains embedded Tomcat or Jetty. And if it is not desired by us, we can always use war plugin and create regular, traditional war and deploy it in classical way.
Spring Boot has also great documentation and I strongly encourage to read it by everybody interested in this tool: Spring Boot Docs

Inconsistent Dependency Injection to domains with Grails

I've encountered strange behavior with a domain class in my project: services that should be injected were null. I've became suspicious as why is that? Services are injected properly in other domain classes so why this one is different?

Constructors experiment

I've created an experiment. I've created empty LibraryService that should be injected and Book domain class like this:

Book has 4 explicit constructors. I want to check which constructor is injecting dependecies. This is my method that constructs Book objects and I called it in controller:

class BookController {
def index() {

static constructAndExamineBooks() {
println("Started constructAndExamineBooks")
Book book1 = new Book().logInjectedService()
Book book2 = new Book("foo").logInjectedService()
Book book3 = new Book("foo", 'bar').logInjectedService()
Book book4 = new Book("foo", 'bar', 100).logInjectedService()
Book book5 = new Book(author: "foo", title: 'bar')
println("Finished constructor Book(Map params)")


Output looks like this:

What do we see?

  1. Empty constructor injects dependencies.
  2. Constructor that invokes empty constructor explicitly injects dependencies.
  3. Constructor that invokes parent's constructor explicitly does not inject dependencies.
  4. Constructor without any explicit call declared does not call empty constructor thus it does not inject dependencies.
  5. Constructor provied by Grails with a map as a parameter invokes empty constructor and injects dependencies.


Always explicitily invoke empty constructor in your Grail domain classes to ensure Dependency Injection! I didn't know until today either!

Browser caches user authorities when using Waffle security

When using Waffle security (with Spring security, in my case) I discovered that both Internet Explorer (9) and Firefox (5) caches authorities bounded to user. I discovered this when I've chagned required user group to access my application and then I added current user to required group but no change. I couldn't gain access. After some debugging it appeared that Waffle returns unchanged set of authorities for current user. Reloading browser, tomcat and clearing all caches and data didn't work. I'm sure that Chrome would work neither. Firefox has convenient way to clear active logins. Click Tools-> Clear recent history -> [check]active logins Finally I got the solution - user should logout and login again into windows box...

Spring security authentication-success-handler-ref and authentication-failure-handler-ref does not work with KerberosServiceAuthenticationProvider

I'm using SpringSecurity with KerberosServiceAuthenticationProvider which is Kerberos security extension. You can read how to use it on extension author's blog. But you cannot use handler on form-login to catch authorization result. It's because of inner construction of authorization filter chain calls. Maybe it can be considered a bug? The workaround is to implement ApplicationListener<AuthenticationSuccessEvent> and ApplicationListener<AbstractAuthenticationFailureEvent> to catch proper events.
package pl.touk.app.fe.server.security;
import org.springframework.context.ApplicationListener; import org.springframework.security.authentication.event.AuthenticationSuccessEvent; public class UserSuccessfulLoginLogger implements ApplicationListener{ @Override public void onApplicationEvent(AuthenticationSuccessEvent event) { //do something here } }  
package pl.touk.app.fe.server.security;
import org.springframework.context.ApplicationListener; import org.springframework.security.authentication.event.AbstractAuthenticationFailureEvent; public class UserFailedLoginLogger implements ApplicationListener{ @Override public void onApplicationEvent(AbstractAuthenticationFailureEvent event) { //do something here } } Then you init beans in Spring configuration

A drawback is that one cannot have access to request and response as could have when using authentication-success-handler-ref and authentication-failure-handler-ref.
But in my case I didn't need that.

Tip! If you cannot receive AuthenticationEvents look at this page.