tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?
Date Mon, 21 Jun 2010 00:22:30 GMT

On Jun 20, 2010, at 1:09 PM, Laird Nelson wrote:

> This ra.xml file is actually ONLY USED DURING UNIT TESTING.  The reason it
> is not included in src/test/resources/META-INF instead is due to an OpenEJB
> issue.  Briefly, src/test/resources/META-INF must contain an empty
> ejb-jar.xml for OpenEJB to run the unit tests appropriately.  If such a file
> exists, an ra.xml file cannot also exist there, since OpenEJB will not be
> able to deploy the resource adapter it represents.  Consequently, we produce
> this ra.xml as a "main" resource, not a "test" resource, so that OpenEJB
> finds both the resource adapter and the @LocalClient.

Side note on this one -- it's always bugged me too.

It's a tiny bit of work but conceptually simple.  90% of the work would be local to the DeploymentLoader
class:

  http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/DeploymentLoader.java

Essentially the 'discoverModuleType' method would get reworked to not have return statements
and instead add the types to a list and return a list -- renaming that method to 'discoverModuleTypes'.
 The 'public AppModule load(File jarFile) throws OpenEJBException' method would be altered
to iterate over the list and create modules for each one.  That method already returns an
AppModule, so the code downstream of it is already looking at all "standalone" modules (say
a single ejb-jar.xml) as ears.  So the rest of the code is essentially already ready for it.


-David


Mime
View raw message