tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laird Nelson <>
Subject Re: Unit/integration testing a RAR with OpenEJB?
Date Tue, 06 Apr 2010 13:52:20 GMT
Ha HA!  Figured it out, and boy is this a hack.  But mysteriously I'm still
proud of it.

So, to do a RAR right in Maven, you really should have two projects (and
this makes a certain amount of sense): the project housing the classes you
write to make the resource adapter work (of type jar, obviously) and the
project to house the actual rar file (of type rar).

At some level, you'd like to test the jar project before you build it, so
that the (effectively brain dead stupid) rar project won't bundle up a bunch
of ra classes that don't work.

So in the jar project, you place your ejb-jar.xml file in
src/test/resources/META-INF, as you'd expect (in an OpenEJB world).  You
annotate your test class with @LocalClient, and add a @Resource injection
for your resource adapter.

Now the problem: how are you going to get OpenEJB to find your resource
adapter?  You can't include ra.xml in src/test/resources/META-INF, because
that's already "claimed" by the ejb-jar file.  That is, when OpenEJB does
its discovery thing--or, as I found out, even if you point at test-classes
with an openejb.conf--if it finds an ejb-jar.xml file, it stops after that.
So OpenEJB, in other words, will find your @LocalClient, but won't find your

What I did to get around this was simply to add this to the pom:


So effectively you store your ra.xml in src/main/resources/META-INF, and
your ejb-jar.xml in src/test/resources/META-INF.  These end up being dumped
in two different classpath entries: classes and test-classes respectively.
But because you exclude META-INF/ra.xml from the final jar file, you are
effectively only using the ra.xml file for tests.

At the end of the day, this is perfect: you get a pristine ra.xml-free jar
file that nevertheless has been unit tested by OpenEJB as a valid resource

Then in your rar project, you simply depend on the jar project, and there's
no further testing to do.

I hope this helps people.


On Tue, Apr 6, 2010 at 9:41 AM, Stephen Connolly <> wrote:

> It you are willing to ditch the ra.xml file from your testing, you can use
> a
> service.xml to define your resource adapter for openejb and then use an
> InitialContext property to define the resource adapter via that
> service.xml...
> Other than that I gave up after much hacking
> On 6 April 2010 14:05, Laird Nelson <> wrote:
> > I have a Maven 2 rar project.  The rar project itself is "empty" except
> for
> > its ra.xml file; it pulls in the actual resource adapter by way of Maven
> > dependencies.  I understand from the Maven guys that this is the way to
> do
> > it.
> >
> > Now I'm faced with figuring out how to test this thing.  I would like to
> > add
> > a test case in the rar project that gets annotated with the @LocalClient
> > annotation, but now I have (apparently) an OpenEJB quandary.
> >
> > The quandary is this: to get my test case discovered by OpenEJB, I've
> > put--in src/test/resources/META-INF--an ejb-jar.xml file that is empty
> > except for the <ejb-jar/> element.  This has worked just fine in other
> > OpenEJB-using tests I've done in the past.
> >
> > The problem now is that the rar project is not actually built--that is,
> my
> > test has to pass before the .rar file will be assembled (after all,
> that's
> > what a unit test is for).  So using some Maven hackery I manage to make
> the
> > src/main/rar/META-INF/ra.xml file show up in the test classpath.
> >
> > If you're keeping score, OpenEJB can now see a META-INF directory with
> > *both* an ejb-jar.xml and an ra.xml file in there.
> >
> > As it turns out, OpenEJB discovers the ejb-jar.xml file, and, apparently
> > satisfied that its discovery is complete, stops right there and doesn't
> > pick
> > up the ra.xml.
> >
> > Is there a way to tell OpenEJB in a Maven unit test setting that it
> should
> > look for BOTH the ejb-jar.xml file (i.e. find the @LocalClient test) AND
> > the
> > ra.xml (i.e. realize that there's an exploded rar that should be
> deployed?
> >
> > Thanks,
> > Laird
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message