Unit/integration testing a RAR with OpenEJB?

[Laird Nelson <lj...@gmail.com>]

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

Re: Unit/integration testing a RAR with OpenEJB?

[David Blevins <da...@visi.com>]

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.

-David

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 <
> stephen.alan.connolly@gmail.com> 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 <lj...@gmail.com> 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
>>>
>>

Re: Unit/integration testing a RAR with OpenEJB?

[Laird Nelson <lj...@gmail.com>]

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 <
stephen.alan.connolly@gmail.com> 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 <lj...@gmail.com> 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
> >
>

Re: Unit/integration testing a RAR with OpenEJB?

[Stephen Connolly <st...@gmail.com>]

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 <lj...@gmail.com> 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
>