BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Resource Injection in the Java EE platform Overview

by Floyd Marinescu on Jun 12, 2006 |
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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT