tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Need help getting Derby running in JUnit
Date Tue, 23 Nov 2010 18:00:57 GMT
On Tue, Nov 23, 2010 at 7:23 AM, Tony Tubbs <> wrote:
>> From: David Blevins <>
>> If you want to do things the portable  way, your bean has to declare a
>> reference to the resource via xml or  annotation:
>> This  doc is still a work in progress, but has some info on Java EE and  JNDI:
> 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

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

 - - - 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:

You can get the same kind of injection into the testcase itself via a
slightly different technique:

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!


View raw message