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

Question

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 EJBs.

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.

Answer 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).

Answer 2

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).