Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Resource and Dependency Injection in Java EE 7

DZone 's Guide to

Resource and Dependency Injection in Java EE 7

Want to learn more about resource and dependency injections in Java EE 7? Click here to learn more about CDIs and EJBs in this tutorial.

· Java Zone ·
Free Resource

Contexts and Dependency Injection (CDI) is a feature of Java EE that helps meld the web tier and transactional tier of its platform that is included in Java EE 6 and higher. From a technical perspective, what this means is that CDI offers a dependency injection framework and also manages the dependencies’ lifecycle.

In this tutorial, we will be covering CDI for Java EE 7.

Contexts and Dependency Injection Specification

As mentioned on Oracle’s Java EE 7 website, Java EE 7 uses CDI 1.1, which is outlined in JSR 346.

CDI 1.1 brought many major changes, as mentioned in this blog post by the CDI lead Pete Muir, including:

  • Global enablement of interceptors, global enablement of decorators, and alternatives using the @Priority annotation
  • Support for the @AroundConstruct  lifecycle callback for constructors
  •  EventMetadata allows inspection of event metadata
  • Allowing binding interceptors to constructors

As mentioned, other significant changes are mentioned in the blog post, and it is encouraged that they are all reviewed.

Comparing Dependency Injection and Resource Injection

Injection Type Can Inject JNDI Resources Directly Can Inject Regular Classes Directly Resolves By Typesafe
Resource Injection True False Resource name No
Dependency Injection False True Type Yes

Dependency Injection

Dependency injection allows us to turn regular Java classes into managed objects and to inject those managed objects into other managed objects. The hurdle is ensuring we are providing the correct managed object at the right time.

Here, we have an @Inject annotation that denotes that we will be providing — also known as injecting — a dependency to this constructor:

@Inject
    public MaskingDataProcessor(MaskingData maskingData) {
        this.maskingData = maskingData;

    }


So, where does this dependency come from?

We have two classes in this example: SSNDataMasker and  BirthdayMasker, and they both implement the same interface.

 SSNDataMasker is annotated to be the default and, therefore, will be chosen by default if available:

@Default
public class SSNMasker implements MaskingData {

    ...
}


 BirthdayMasker is annotated to be the alternative dependency and, therefore, will be chosen if  SSNDataMasker is unavailable:

@Alternative
public class BirthdayMasker implements MaskingData {

    ...
}


Resource Injection

Resource injection allows us to inject any resource available in the JNDI namespace into any object managed by the container. For instance, we can use resource injection to inject connectors, data sources, or any other resources available in the JNDI namespace.

In the code below, we inject a data source object into a field, and this kind of resource injection is appropriately called field-based injection:

public class MyClass {
     @Resource(name="java:comp/SomeDataSource")
    private DataSource myDataBase;
    ...
}


Another way of injecting resources is method-based injection. In method-based injection, the parameter that is passed is injected with the resource:

public class MyClass {

    private DataSource myDataBase;
        ...

    @Resource(name="java:comp/SomeDataSource")
    public void setMyDataSource(DataSource dataSource) {
        myDataBase = dataSource;
    }
}


What’s the Difference Between EJB and CDI?

As this article on the Oracle website states, the “C” in CDI is the main difference between EJB beans and CDI beans. EJB components might be stateful, but they are not inherently contextual. When we reference a stateful component instance, it must be explicitly passed between clients and destroyed by the application. CDI improves the EJB component model with contextual lifecycle management. However, there are times when we want to use one over another.

When to Use EJB

There are several useful container services that are available only if we make our CDI bean also an EJB by adding  @Stateful,  @Stateless, or  @Singleton.

Examples include:

  • When we are exposing a JAX-WS  @WebService, making it an EJB allows us to not have to list it and map it as a servlet in the xmlfile. This is available to  @Stateless and  @Singleton.
  • When we are exposing a JAX-RS resource via  @Path and when the RESTful service is an EJB, we get automatic discovery and don’t need to add it to a JAX-RS Application subclass or elsewhere. This is available to @Stateless and  @Singleton.
  • When we are working in parallel, the @Asynchronous method invocation is useful. As we know, having too many threads can degrade performance. The  @Asynchronous annotation allows us to parallelize things we do using the container’s thread pool. This is available to  @Stateful,  @Stateless, and  @Singleton.

When to Use CDI

Simply put, we should use CDI when we benefit from its use. When we need injection, events, interceptors, decorators, lifecycle tracking, and other features that CDI offers.

Conclusion

To quickly test the concepts we reviewed regarding CDI, let’s add Weld to a Maven project:

<dependency>
    <groupId>org.jboss.weld.se</groupId>
    <artifactId>weld-se-core</artifactId>
    <version>2.4.1.Final</version>
</dependency>


Assuming we already have code to test – such as the code previously mentioned in the blog post – we just need to execute  Weld, like:

public static void main(String[] args) {

    Weld weld = new Weld();
    WeldContainer container = weld.initialize();
    MaskingDataProcessor maskingDataProcessor = container.select(MaskingDataProcessor.class).get();
    container.shutdown();
    }


Topics:
java ,java 7 ,java ee 7 ,tutorial ,dependency injections ,cdi ,resource injection ,ejb

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}