Can I make arbitrary classes "injectable" in Java EE?

I'm working on a large legacy application using stateless session beans that has recently been migrated from EJB2 to EJB3, and I'd like to use dependency injection. Unfortunately, in a (IMO misguided) attempt to achieve decoupling, all actual business logic lies in "manager" classes to which the session beans forward their calls. Those manager classes then often use other E开发者_开发知识库JBs.

Can I somehow make these manager classes capable of being injected into the EJBs via @Resource and then having the other EJBs injected into them via @EJB?

The application has to run on glassfish 2.1.

---

(...) all actual business logic lies in "manager" classes to which the session beans forward their calls.

That was a very common pattern with EJB 2.x allowing to unit test the "manager" classes easily, outside the container, without any adherence to the EJB API.

Can I somehow make these manager classes capable of being injected into the EJBs via @Resource and then having the other EJBs injected into them via @EJB?

Not out-of-the-box with Java EE 5. 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.

In Java EE 6, this would be possible using CDI (JSR-199) and the @Inject annotation in EJBs to inject your managers and also in you managers to get EJBs injected.

Maybe you could try to deploy Weld (the RI of JSR-199) as part of your application on GlassFish v2.1. I didn't experiment this myself, so I can't confirm anything. Just in case, maybe have a look at the Chapter 18. Application servers and environments supported by Weld (GlassFish v2.1 hasn't been tested, but it doesn't mean it doesn't work).

---

Pascal's suggestion about upgrading to GlassFish 3 sounds probably like the most elegant approach ;) I'd be curious to hear what prevents moving to a more recent version (not saying there can't be a reason, just wondering what the issue is here).