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:
SessionContext
objectDataSources
objectUserTransaction
EntityManager
interfaceTimerService
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.
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.
Community comments
Injection should be extendable
by Tim Fennell,
Yes, interesting...
by Jason Carreira,
Injection should be extendable
by Tim Fennell,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.