On Nov 26, 2007, at 11:26 AM, Paul Spencer wrote:
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 :)
Right :)
What I was just typing up in another email is that we would like to
find some way to support what you were trying to do; a standard JUnit
TestCase subclass with dependency injection annotations.
An option I've suggested in the past would be something simple like
this.
public class EjbDiTest extends TestCase {
@EJB private DataReaderLocal dataReaderLocal;
@EJB private DataReaderRemote dataReaderRemote;
private InitialContext initialContext;
protected void setUp() throws Exception {
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
properties.setProperty("openejb.deployments.classpath.include",
".*injection.*");
properties.put("openejb.inject", this); // <------ you give
us a reference to your test case
initialContext = new InitialContext(properties);
}
}
Then we do the injection on your test case.
Internally, it's much trickier as we'd like to support not just @EJB
but also @Resource and the rules that make those two annotations work
can get pretty complex. The way the code is written now, we'd
essentially have to treat the test case as an app client and run it
through deployment where all its references to ejbs and datasources,
etc. would get resolved.
That's one theory anyway.
Would something like that work for you or is the knowledge that the
test case would be relying on something outside the (current) EJB spec
enough to make those lookups look not so bad?
-David
