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
