tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Problems getting EJB via annotation in test class.
Date Mon, 26 Nov 2007 20:54:12 GMT

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  

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


View raw message