David,
To summarize things:
Relative to testing EJBs inside a Maven executed JUnit test, any object
instantiated by a class inside a JUnit test case is not "container
managed" thus the object will not receive the benefit of DI. EJB known
to the embedded EJB container, ejbd in this case, and instantiated
within that container will receive the benefit of DI, but the beans must
be retrieve by the test class via a JNDI lookup.
Now I can stop beating my head against the wall :)
Thank you David and Jacek
Paul Spencer
David Blevins wrote:
On Nov 25, 2007, at 2:09 PM, Paul Spencer wrote:
I am trying to access the many forms of the EJB, some may be incorrect
an need to be removed from the test.
Since the test is using OpenEJB as an embedded server, why is the test
class not considered as a DI target?
My intent is to test the EJB in the same manor as an application would
use the EJB. This includes the use of DI. Is my implementation
consistent with my intent?
As Jacek points out of you'd like to test your EJBs from the perspective
of another application, you'd have to put your test logic in an actual
application (ejb and/or interceptor) and execute it from your test case.
The EJB 3.0 specification only covers dependency injection for classes
managed by a container:
- servlets, servlet filters, listeners
- a javaee app client ran by an app client container
- ejb session beans or interceptors
In the EJB 3.1 expert group we plan to introduce some way for
non-managed objects (objects not instantiated or run by a container) to
get dependency injection. No details on how that will be done just yet,
however I can nearly guarantee it'll be in the form of some code you
have to execute on your object after you construct it, i.e. all the
injection won't magically be done on the "new MyClass()" call.
We definitely discussed the magical "new" in EJB 3.0 in reference to JPA
and decided against using anything like that because the only possible
way to support it is through byte-code manipulation. At the time
byte-code manipulation was only possible via using some vendor tool at
build time or dynamically using a vendor javaagent specified on the
command line, both of which are fairly complicated and diminish the
simplicity we were going for. Things are different with Java 6 so maybe
we'll see some magic news in Java EE some day.
-David
