user2695214 wrote:It seems that your work manager class is not a managed bean of any sort, that's why the injection also fails. You could make your work manager class a @ManagedBean, that'd probably be the best move.
This seems to be a viable work around, but are there any issues of doing it this way in the long run? For example, is it possible that the myDAO object will be cleaned up or destroyed while processing MyWork. My thought is that myDAO was created with dependency injection into another class (MyStartupClass and not MyWork).
Is this the correct way of calling EJB/DAO classes from work managers or is the a better way of injecting EJB classes into work managers?
Kayaman wrote:It will probably work, but it isn't really how EJBs were designed. The container is there to manage instances to EJBs, when you start passing them to the constructor of a non-managed class, implying it will be assigned to a class member for later use, you're inviting resource leaks. Might be that the reference just sticks forever preventing the EJB instance to actually be returned to the container's control at some point.
However, if you do pass the DAO through the constructor, there is no risk. It won't magically disappear or stop working.
Kayaman wrote:Well that would depend on how the instance of this worker is constructed of course. If it is part of some grander framework / technology stack then it might not be possible to turn it into an EJB.
Oops, you're right. I missed the DAO being an EJB. That should definitely be fetched from JNDI, or better yet, make the worker a managed bean (providing high enough Java EE level).
user2695214 wrote:Its mostly difficult because you're using old tech. If you would target JEE6 you can benefit from standardized global JNDI names. The problem was recognized and fixed, but you have to move along with the times to benefit from improvements.
Thanks to everyone who replied. I really didn't think this would be so difficult.