Resource Injection in the Java EE platform Overview

Posted by Floyd Marinescu on Jun 12, 2006

Sections

Development,

Architecture & Design

Topics

Programming ,

Java

Tags

Java EE ,

Annotations ,

Dependency Injection

One of the simplification features of Java EE 5 is the implementation of basic dependency injection to simplify web and EJB components. Dependency injection, called resource injection by the spec designers uses annotations or XML descriptors to declare resources or environment entries used by a class, eliminating JNDI lookups. Life-cycle hooks can also be declared with annotations.   A new tutorial on java.sun.com gives a quick overview of how to use annotations to do resource injection and simplify access to resource and environment data injection, as well as life-cycle control.   Another good source for what's new in EE 5 is the introduction to the Java EE platform article.

Java EE 5 can handle injections transparently when used on container managed components.  From the Java EE 5 spec, the following Java EE components support injection and the post/pre construct annotations:


Typically injection will occur after an instance of the class is constructed, but before any business methods are called. Method injection is also supported.

Injection is limited only to first class constructs defined in the Java EE platform, including:

• SessionContext object
• DataSources object
• UserTransaction
• EntityManager interface
• TimerService interface
• Other enterprise beans
• Web services
• Message queues and topics
• Connection factories for resource adaptes
• Environment entries limited to String, Character, Byte, Short, Integer, Long, Boolean, Double, and Float.
  

The injection facilities in Java EE 5 do not apply to any POJO (which is often criticized by the Spring community) or two JSPs, Tag files, and certain JSF constructs:

Supporting resource injection on JavaServer Faces technology renderers, converters, or validators is not desirable because that would violate Model-View-Controller (MVC) separation of these presentation objects.  If these classes need to get access to resources, they should do so through a managed bean

It is interesting to note that the Java standards emphasize Annotation-driven injection, while the Spring community which popularized dependency injection continues to ignore annotations as a means of injection, using XML descriptors instead.

1. Back to top

   Injection should be extendable

   by Tim Fennell

   Firstly, I think resource injection in servlets is a bit of a joke. Not many developers write servlets any more; almost everyone uses one of the infamously many web frameworks and stays away from Servlets all together.
   
   But more importantly, this just doesn't seem to cut it as a DI implementation. If you want DI and plan to use it, you're going to be hamstrung by the fact that you can't inject arbitrary classes from arbitrary sources - something you can do with most DI containers. Why there isn't a way to extend the object locator/factory side of things I'll never know. I mean, how hard would it have been to provide an interface (say ResourceFactory) and a way to register implementations? Then developers could use a consistent set of annotations to inject "enterprise" resources, spring beans and anything else they choose.
   
   -Tim Fennell
   Stripes: Because web development should just be easier

   Reply

2. Back to top

   Yes, interesting...

   by Jason Carreira

   
   It is interesting to note that the Java standards emphasize Annotation-driven injection, while the Spring community which popularized dependency injection continues to ignore annotations as a means of injection, using XML descriptors instead.
   

   
   
   Dependency Injection was originally known as Inversion of Control (IoC). Some of the intent has been lost, perhaps, in the renaming. If I specify IN MY CLASS what should be injected, then how is the dependency inverted? Then it's just a shorthand for a registry lookup / locator.
   
   By specifying how things are wired externally, I can create truly reusable classes which aren't dependent on a certain deployment environment, just the contract that something implementing this interface I depend on will be supplied to be before I need it. Is it massively different in implementation? No, not really, but it is very different conceptually, and those conceptual differences show up in the implementation, the literature about the frameworks / specs, and in how you build systems using them.

   Reply

• Older >