tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Load time dependency ordering problem
Date Sat, 09 Feb 2008 02:44:45 GMT

On Feb 8, 2008, at 10:32 AM, Jack Cox wrote:

> I'm trying to setup a 'out-of-container' test rig to test both a set  
> of
> session beans and entity beans with openEJB.  The session beans  
> depend on
> the entity beans.  The session bean class files are located in one  
> directory
> tree, and the entity beans in another (they are two different Eclipse
> projects).
> I've defined the dependencies in the openejb.xml config file as:
> <Deployments dir="vwc-masterdata-entity/classes" />
> <Deployments dir="vwc-masterdata-service/classes" />
> OpenEJB finds EJBs in both directory trees (as it should).
> But when the container tries to inject the entity beans into the  
> session
> beans I get the following error (stack dump eliminated for brevity)
> This leads me to believe that the entities have not been resolved  
> before the
> session beans start loading.  Is there a way to instruct the loader  
> as to
> the order in which things are loaded so that the entities get  
> defined before
> they are required by the session beans?

It might be possible to create an application.xml in the module  
containing the tests, which would ensure they're deployed as one group.

So say for example:


Where vwc-masterdata-foo is the module that has your test cases.  The  
paths listed in an application.xml are resolved relative to the ear  
path (in this case "vwc-masterdata-foo/classes"),  so something like  
this should work:


Course, this is all assuming your tests are in some third eclipse  
module and not in vwc-masterdata-service or vwc-masterdata-entity.   
Definitely let us know if that's not the case.

The thing, aside from order, that would prevent it from working as-is  
is that local references between ejb-jars not in the same ear don't  
work as we assume they are in different classloaders and we must  
serialize/deserialize to get from one classloader to the other.  But  
I'd guess that your eclipse project is smushing everything into the  
same classloader already and we could find a way to detect that and  
roll them together automatically as an ear for you.

Let us know if the suggestion doesn't work or doesn't really fit what  
you'd like to do -- we are very happy to add support to really fit  
what you need.  We support auto finding apps in the classpath  
(eliminating the need for the Deployments elements in an openejb.xml),  
when we do that we know in advance what classloader they come from and  
could easily roll them into one ear instead of creating one ear each  
as we do now.


View raw message