On Tue, Nov 23, 2010 at 7:23 AM, Tony Tubbs <[email protected]> wrote: >> From: David Blevins <[email protected]> > >> If you want to do things the portable way, your bean has to declare a >> reference to the resource via xml or annotation: >> >> http://openejb.apache.org/3.0/resource-ref-for-datasource.html >> >> This doc is still a work in progress, but has some info on Java EE and >> JNDI: >> >> http://openejb.apache.org/3.0/basics-getting-things.html > > I'm confused. > > - Re: link #1 above. The example code is NOT passing parameters to the "new > InitialContext()" call as explained to do for JUnit testing elsewhere. From > link #2, I understand this to be necessary if I want to make use of the > "java:/comp/env..." naming used throughout my code base.
Correct on both counts. And the implication as you notice is that you cannot use "java:comp/env" lookups in your test case, just your EJBs. Bottom line is that your testing code and your production code will be using slightly different techniques to lookup things. The testcase will use the LocalInitialContextFactory approach and the EJBs will use the no-arg "new InitialContext()" approach. Why can't we make "java:comp/env" lookups work in a test case? Well the short answer is this aspect of JNDI was very badly designed. The "java:comp/env" namespace is not a global namespace, but relative to each EJB. So one EJB can define "java:comp/env/Foo" to point to a datasource, while another EJB in the exact same jar can define "java:comp/env/Foo" to point to say a JMS topic. Under the covers the container has to use ThreadLocals and similar to techniques to know "who's asking" and what the lookup should return. So if a testcase were to lookup "java:comp/env/Foo", what would the desired behavior be? Do they get the DataSource or the JMS Topic? If there are three EJBs we will have three separate "java:comp/env" namespaces, each possibly conflicting. Do we just pick one randomly? Maybe we should at support so the testcase can define its own "java:comp/env" like each EJB can? Bottom line in that regard is it would still be vendor specific, so it really isn't anyone's best interests for us to make vendor specific behavior falsely appear to be portable. In Java EE 6 there are new namespaces, "java:global/", "java:app/" and "java:module/" and each is scoped. In the future, the testcase will be able to lookup via "java:global" or "java:app". The downside is that there are more namespaces to think about and learn how to configure. - - - Non lookup approach - - - If you cut out JNDI and use injection instead, you can get a lot of that complexity out of both your production code and your testcases for your production code. Here's an example that shows dependency injection of a datasource in an EJB: http://openejb.apache.org/3.0/injection-of-datasource-example.html You can get the same kind of injection into the testcase itself via a slightly different technique: http://openejb.apache.org/3.0/local-client-injection.html There's an example for that one in the examples zip as well in the "testcase-injection" dir. > Still trying to get some sort of xml configuration to work for 'a more > portable > way', I've stubbed out the following ejb-jar.xml. It loads w/o errors, but I > can still only do lookups using "openejb:Resource/WTSHARE" for my datasource > and > the simple class name for the EJBs (i.e. just "AdvisorListFacadeLocal" not > "java:comp/env/AdvisorListFacade" as desired). The xml looks fine, but if you didn't use the no-arg "new InitialContext()" in the EJB code that does the lookup than no "java:comp/env" lookups will work. It's also possible to set things up to use the annotation approach and then instruct OpenEJB to spit out an equivalent xml descriptor via setting the "openejb.descriptors.output" system property to "true". It can also be specified in the InitialContext params. So even if there was a strong desire to not use annotations, you could still use them long enough to get OpenEJB to create all the xml for you. After which point you can just keep the xml and loose the annotations. Hope this helps! -David
