I'm a Java software developer, consultant and architect that focuses on enterprise applications, quality and performance. I gained interest in Java due to it's open nature and community support. Next to Java, I spend most of my time trying to stay up to date with everything that moves inside the software world like Scala and NoSQL db's. Jelle is a DZone MVB and is not an employee of DZone and has posted 12 posts at DZone. You can read more from them at their website. View Full User Profile

Java EE6 CDI, Named Components and Qualifiers

06.23.2011
| 18081 views |
  • submit to reddit

One of the biggest promises java EE6 made, was to ease the use of dependency injection. They did, using CDI. CDI, which stands for Contexts and Dependency Injection for Java EE, offers a base set to apply dependency injection in your enterprise application.
Before CDI, EJB 3 also introduced dependency injection, but this was a bit basic. You could inject an EJB (statefull or stateless) into another EJB or Servlet (if you container supported this). Offcourse not every application needs EJB’s, that is why CDI is gaining so much popularity.
To start, I have made this example. There is a Payment interface, and 2 implementations. A cash payment and a visa payment.
I want to be able to choose witch type of payment I inject, still using the same interface.

public interface Payment {
    void pay(BigDecimal amount);
}

and the 2 implementations

public class CashPaymentImpl implements Payment {
 
    private static final Logger LOGGER = Logger.getLogger(CashPaymentImpl.class.toString());
 
    @Override
    public void pay(BigDecimal amount) {
        LOGGER.log(Level.INFO, "payed {0} cash", amount.toString());
    }
}
public class VisaPaymentImpl implements Payment {
 
    private static final Logger LOGGER = Logger.getLogger(VisaPaymentImpl.class.toString());
 
    @Override
    public void pay(BigDecimal amount) {
        LOGGER.log(Level.INFO, "payed {0} with visa", amount.toString());
    }
}

To inject the interface we use the @Inject annotation. The annotation does basically what it says. It injects a component, that is available in your application.

1@Inject private Payment payment;

Off course, you saw this coming from a mile away, this won’t work. The container has 2 implementations of our Payment interface, so he does not know which one to inject.

Unsatisfied dependencies for type [Payment] with qualifiers [@Default] at injection point [[field] @Inject private be.styledideas.blog.qualifier.web.PaymentBackingAction.payment]

So we need some sort of qualifier to point out what implementation we want. CDI offers the @Named Annotation, allowing you to give a name to an implementation.

@Named("cash")
public class CashPaymentImpl implements Payment {
 
    private static final Logger LOGGER = Logger.getLogger(CashPaymentImpl.class.toString());
 
    @Override
    public void pay(BigDecimal amount) {
        LOGGER.log(Level.INFO, "payed {0} cash", amount.toString());
    }
}
@Named("visa")
public class VisaPaymentImpl implements Payment {
 
    private static final Logger LOGGER = Logger.getLogger(VisaPaymentImpl.class.toString());
 
    @Override
    public void pay(BigDecimal amount) {
        LOGGER.log(Level.INFO, "payed {0} with visa", amount.toString());
    }
}

When we now change our injection code, we can specify wich implementation we need.

@Inject private @Named("visa") Payment payment;

This works, but the flexibility is limited. When we want to rename our @Named parameter, we have to change it on everyplace where it is used. There is also no refactoring support.
There is a beter alternative using Custom made annotations using the @Qualifier annotation. Let us change the code a little bit.
First of all, we create new Annotation types.

@java.lang.annotation.Documented
@java.lang.annotation.Retention(RetentionPolicy.RUNTIME)
@javax.inject.Qualifier
public @interface CashPayment {}
@java.lang.annotation.Documented
@java.lang.annotation.Retention(RetentionPolicy.RUNTIME)
@javax.inject.Qualifier
public @interface VisaPayment {}

The @Qualifier annotation that is added to the annotation, makes this annotation discoverable by the container. We can now simply add these annotations to our implementations.

@CashPayment
public class CashPaymentImpl implements Payment {
 
    private static final Logger LOGGER = Logger.getLogger(CashPaymentImpl.class.toString());
 
    @Override
    public void pay(BigDecimal amount) {
        LOGGER.log(Level.INFO, "payed {0} cash", amount.toString());
    }
}
@VisaPayment
public class VisaPaymentImpl implements Payment {
 
    private static final Logger LOGGER = Logger.getLogger(VisaPaymentImpl.class.toString());
 
    @Override
    public void pay(BigDecimal amount) {
        LOGGER.log(Level.INFO, "payed {0} with visa", amount.toString());
    }
}

The only thing we now need to do, is change our injection code to

@Inject private @VisaPayment Payment payment;

When we now change something to our qualifier, we have nice compiler and refactoring support. This also adds extra flexibilty for API or Domain-specific language design.

 

From http://styledideas.be/blog/2011/06/16/java-ee6-cdi-named-components-and-qualifiers/

Published at DZone with permission of Jelle Victoor, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jonathan Fisher replied on Thu, 2011/06/23 - 11:37pm

I <3 CDI, but isn't this like the 12th post on alternatives or qualifiers in the last month??? Either way, well put, great code examples, thanks :D

Robert Bram replied on Fri, 2011/06/24 - 3:07am

Can't (wouldn't) you just inject the concrete class name instead? @Inject private CashPaymentImpl payment;

Wujek Srujek replied on Sat, 2011/06/25 - 4:11am in response to: Robert Bram

Now that's a good question. I haven't been able to understand yet, why is @Inject with a qualifier that is bound to a concrete implementation better than simply @Inject with the concrete implementation itself. If you want to change the injected type, you have to recompile again anyways. The only point I see is that if you inject the concrete impl without qualifier, you might accidently use methods of the impl, not just the interface methods. Then, if you do decide to change the implementation, you can get compilation errors for such methods. Having said that, testing and mocking would show this problem, and since you have to recompile anyways, I am not sure if it's a big deal. Please anybody correct me if I am wrong. Other than the reason stated above, I am clueless about why one would need qualifiers.

Sunny Wales replied on Wed, 2011/12/07 - 12:32am

Simple and exactly I was looking for! Thanks

Sirikant Noori replied on Sun, 2012/01/15 - 12:34pm

I love the DI by annotation evangelists. Yes, you get refactoring (but no real Type check) but you tie your code to an implementation. You’re just breaking the separation of concerns. Use some external configuration to choose your implementation and the right tooling to have refactoring but for sure, don’t use compiler because any injection change will cause a re-compilation. And please, don’t tell me you’ll use the Extension mechanism of CDI cause it’s more boilerplate than loading any file format describing your injections

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.