tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Unit/integration testing a RAR with OpenEJB?
Date Wed, 21 Apr 2010 21:04:03 GMT
Laird, this is an excellent email!  Looks like it's a blog entry  
waiting to be posted.

On a side note, it would be excellent if we could support having the  
ra.xml and ejb-jar.xml in the same classpath entry.  If you're willing  
to poke at it, I could certainly give some good pointers.  I bet  
internally we could just check for the ra.xml and create a "virtual"  
module for it on the fly and then just let all the rest of the  
deployment code continue unchanged as if there were two physical  
modules all along.

Pop on dev@ or on irc if you're interested.


On Apr 6, 2010, at 6:52 AM, Laird Nelson wrote:

> 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
> @Resource.
> What I did to get around this was simply to add this to the pom:
> <build>
>    <plugins>
>      <plugin>
>        <artifactId>maven-jar-plugin</artifactId>
>        <configuration>
>          <excludes>
>            <exclude>META-INF/ra.xml</exclude>
>          </excludes>
>        </configuration>
>      </plugin>
>    </plugins>
>  </build>
> 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
> adapter.
> 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.
> Best,
> Laird
> 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

View raw message