You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Jack Cox <jc...@captechventures.com> on 2008/02/08 19:32:10 UTC
Load time dependency ordering problem
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)
INFO [OpenEJB.startup.config]: Configuring app:
vwc-masterdata-service/classes
FATAL [OpenEJB.startup]: Cannot find bean "CodeTypeFacade/Local" referenced
by bean "CodeService".
WARN [OpenEJB.startup.config]: Jar not loaded.
vwc-masterdata-service/classes. Cannot find bean "CodeTypeFacade/Local"
referenced by bean "CodeService".
org.apache.openejb.OpenEJBException: Cannot find bean "CodeTypeFacade/Local"
referenced by bean "CodeService".
at
org.apache.openejb.config.JndiEncInfoBuilder.buildEjbLocalRefInfos(JndiEncInfoBuilder.java:286)
A little further down in the log file I get the following messages:
INFO [OpenEJB.startup]: Jndi(name=AppAndUserFacade/Local) -->
Ejb(deployment-id=AppAndUserFacade)
INFO [OpenEJB.startup]: Jndi(name=CodeTypeFacade/Local) -->
Ejb(deployment-id=CodeTypeFacade)
INFO [OpenEJB.startup]: Jndi(name=ClaimAdminstratorFacade/Local) -->
Ejb(deployment-id=ClaimAdminstratorFacade)
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?
Thanks,
Jack
--
View this message in context: http://www.nabble.com/Load-time-dependency-ordering-problem-tp15361292p15361292.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Load time dependency ordering problem
Posted by David Blevins <da...@visi.com>.
On Feb 20, 2008, at 6:16 PM, David Blevins wrote:
>
> On Feb 18, 2008, at 7:50 AM, Jack Cox wrote:
>
>>
>> David,
>>
>> Let me know when you've got some code to test and I'll give it a
>> whirl.
Alright, got some code you can test out. With the new code, you have
up until you use the bean for your @EJB references to resolve (or
longer if not using dependency injection). If you're feeling geeky
and want to see the complete list of supported ejb ref scenarios: http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/test/java/org/apache/openejb/assembler/classic/EjbRefTest.java
Anyway, new 3.0-SNAPSHOT jars have been uploaded to our snapshot repo
at http://people.apache.org/repo/m2-snapshot-repository/
If you can give 'em a try that'd be great.
-David
>
>
> Anyway, just an fyi.
>
> -David
>
>>
>> David Blevins wrote:
>>>
>>>
>>> On Feb 11, 2008, at 6:56 AM, Jack Cox wrote:
>>>
>>>> David,
>>>>
>>>> Thanks for the response. Using the application.xml to group the
>>>> class
>>>> directories did not have the desired effect. The loader still sees
>>>> them as
>>>> separate 'jars' and appear to be classloaded separately. In their
>>>> 'in-container' deployment the jar files from these directories are
>>>> within
>>>> the same ear, so they are classloaded together.
>>>>
>>>
>>> FYI, started working on this.
>>>
>>> -David
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/Load-time-dependency-ordering-problem-tp15361292p15546899.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>
>>
>
>
Re: Load time dependency ordering problem
Posted by David Blevins <da...@visi.com>.
On Feb 18, 2008, at 7:50 AM, Jack Cox wrote:
>
> David,
>
> Let me know when you've got some code to test and I'll give it a
> whirl.
I implemented the classpath as one big ear approach and didn't really
like the outcome; essentially all things pass or all things fail as
one big unit which mean one bad app can tank all the rest. Seems the
approach we have now is the most resilient in that regard, just the
ear-to-ear referencing code could be made strong enough to handle
"lazy" references. I.e. improved so the actual order things are
loaded doesn't matter as long as both exists when you actually try to
use the refs. We support something like that now, but it's restricted
to remote interfaces and requires you to know in advance and
explicitly set the deploymentId of the bean you will reference.
Supporting local interfaces should be possible if both apps happen to
be in the same classloader and there's no reason we can't support the
magic mapping rules we currently have for non-lazy refs for objects
deployed in an ear.
Anyway, just an fyi.
-David
>
> David Blevins wrote:
>>
>>
>> On Feb 11, 2008, at 6:56 AM, Jack Cox wrote:
>>
>>> David,
>>>
>>> Thanks for the response. Using the application.xml to group the
>>> class
>>> directories did not have the desired effect. The loader still sees
>>> them as
>>> separate 'jars' and appear to be classloaded separately. In their
>>> 'in-container' deployment the jar files from these directories are
>>> within
>>> the same ear, so they are classloaded together.
>>>
>>
>> FYI, started working on this.
>>
>> -David
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Load-time-dependency-ordering-problem-tp15361292p15546899.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: Load time dependency ordering problem
Posted by Jack Cox <jc...@captechventures.com>.
David,
Let me know when you've got some code to test and I'll give it a whirl.
Jack
David Blevins wrote:
>
>
> On Feb 11, 2008, at 6:56 AM, Jack Cox wrote:
>
>> David,
>>
>> Thanks for the response. Using the application.xml to group the class
>> directories did not have the desired effect. The loader still sees
>> them as
>> separate 'jars' and appear to be classloaded separately. In their
>> 'in-container' deployment the jar files from these directories are
>> within
>> the same ear, so they are classloaded together.
>>
>
> FYI, started working on this.
>
> -David
>
>
>
--
View this message in context: http://www.nabble.com/Load-time-dependency-ordering-problem-tp15361292p15546899.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Load time dependency ordering problem
Posted by David Blevins <da...@visi.com>.
On Feb 11, 2008, at 6:56 AM, Jack Cox wrote:
> David,
>
> Thanks for the response. Using the application.xml to group the class
> directories did not have the desired effect. The loader still sees
> them as
> separate 'jars' and appear to be classloaded separately. In their
> 'in-container' deployment the jar files from these directories are
> within
> the same ear, so they are classloaded together.
>
FYI, started working on this.
-David
Re: Load time dependency ordering problem
Posted by Jack Cox <jc...@captechventures.com>.
David Blevins wrote:
>
>
> 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:
>
> vwc-masterdata-entity/classes
> vwc-masterdata-service/classes
> vwc-masterdata-foo/classes/META-INF/application.xml
>
> 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:
>
> <application>
> <module>
> <ejb>../../vwc-masterdata-entity/classes/</ejb>
> </module>
> <module>
> <ejb>../../vwc-masterdata-service/classes/</ejb>
> </module>
> </application>
>
> 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.
>
> -David
>
>
>
David,
Thanks for the response. Using the application.xml to group the class
directories did not have the desired effect. The loader still sees them as
separate 'jars' and appear to be classloaded separately. In their
'in-container' deployment the jar files from these directories are within
the same ear, so they are classloaded together.
-Jack
--
View this message in context: http://www.nabble.com/Load-time-dependency-ordering-problem-tp15361292p15412772.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Load time dependency ordering problem
Posted by David Blevins <da...@visi.com>.
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:
vwc-masterdata-entity/classes
vwc-masterdata-service/classes
vwc-masterdata-foo/classes/META-INF/application.xml
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:
<application>
<module>
<ejb>../../vwc-masterdata-entity/classes/</ejb>
</module>
<module>
<ejb>../../vwc-masterdata-service/classes/</ejb>
</module>
</application>
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.
-David