Resource Injection in the Java EE platform Overview
- Share
-
- |
Read later
Reading List
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:
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.
2
Discuss
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:
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:
SessionContextobjectDataSourcesobjectUserTransactionEntityManagerinterfaceTimerServiceinterface- 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.
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 beanIt 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.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login 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
Community comments
Injection should be extendable
by
Tim Fennell
Posted
Yes, interesting...
by
Jason Carreira
Posted
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
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.
