Java Magazine - Premiere Issue 2011

//enterprise java /

Resource Injection with
Java EE 6
ADAM BIEN
Learn about the various annotations that are available for resource injection
with Java EE 6, why they are needed, and when they can be used.

JAVA IN ACTION

Should you use @Resource, @Inject, @PersistenceContext, or plain old Java Naming and Directory Interface (JNDI) lookup? Java Platform, Enterprise Edition 6 (Java EE 6) offers multiple possibilities for injection of configured resources, such as a datasource, destination, Java Persistence API (JPA) EntityManager, Java Transaction API (JTA) User Transaction, URL, J2EE Connector Architecture (JCA) connector, mail session, LDAP connection, and even a custom resource installed in JNDI. So why do we need several annotations for resource injection?

This article describes the various annotations that are available for resource injection with Java EE 6, why they are needed, and when they can be used.

@Resource—The Generic JNDI
Resource Injector
The @Resource annotation is
defined in JSR-250, “Common
Annotations for the Java
Platform.” This specification also
includes other well-known anno-
tations such as @PreDestroy,
@PostConstruct, and @Roles
Allowed. While JSR-250 is required
in Java EE 5 and Java EE 6, it is
defined as an independent Java
EE specification and, thus, it can
be used by any other non-Java
EE frameworks or libraries. Some
of the JSR-250 annotations are
even packaged with Java Platform,
Standard Edition (Java SE). This is
the case for @Resource.

@Resource(name="jdbc/sample")

DataSource ds;

}
The name element specifies
the actual JNDI name. The data-
source in the above was config-
ured and injected with the JNDI
name jdbc/sample. Because of
the ubiquitous “Convention over
Configuration” principle in Java
EE 6, the name element does
not need to be specified. If it is
not specified, the JNDI name is
derived directly from the field
name. This would be difficult in
our case. The code would look
like @Resource DataSource jdbc/
sample, and it would not com-
pile. The change of the applica-
tion server configuration would
break the code and require the
field to be renamed. In this
particular case, it is better to
name the JNDI name explicitly.
Renaming the JNDI resource
would affect only the name ele-
ment and not the field name.

The use of mappedName should be avoided. It is proprietary and depends on the application server implementation. Injected resources can be shared and can be configured with the shareable element, which is set to true by default. Most of the resources are either immutable (such as injected primitive types or injected URLs) or resource factories (such as DataSource), and so they are shareable.

The @Resource annotation supports field and setter injection. Field injection is leaner, because it does not require you to implement a superfluous setter. Admittedly, you will need to lose the field visibility to package visibility to allow a mock-out of the injected class during a unit test.