You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2006/09/06 19:37:33 UTC
Head-scratching dependency problem
I'm working my way toward getting a full Geronimo build with the Yoko
ORB, which means a lot of changes to the various plans. In the
client-corba plan, I have the following GBean definition:
<gbean name="ORBConfigAdapter"
class="org.openejb.corba.yoko.ORBConfigAdapterGBean"/>
The ORBConfigAdapterGBean is a new bean that encapsulates the
configuration knowledge of the target ORB implementation. As you might
expect, this has a few references to Yoko-specific classes. While
trying to build this config, I got a NoClassDefFoundError trying to load
one of the Yoko classes. Obviously a dependency problem, so I added the
following dependency to the client-corba/pom.xml file:
<dependency>
<groupId>org.apache.yoko</groupId>
<artifactId>yoko-core</artifactId>
</dependency>
Problem solved, the config built properly and the build sped along until
it hit the j2ee-corba config. This config has the same ORBConfigAdapter
GBean defined. Not surprisingly, I got the same NoClassDefFoundError
for the same class when trying to retrieve the GBeanInfo. Doh! This
should be the same fix as the client-corba problem, so I added the same
dependency lines to j2ee-corba/pom.xml. This time, the error does NOT
go away :-( The dependency is showing up in the generated
target/plan/plan.xml file with the correct version number, the
NoClassDefFoundError seems to be very persistent. I've run out of ideas
on how to fix or debug this problem. Any suggestions on what might be
going wrong?
Rick
Re: Head-scratching dependency problem
Posted by Dain Sundstrom <da...@iq80.com>.
I'd drop a break point near where the NoClassDefFoundError is thrown
and inspect class loader. My guess is that Aaron is right and some
code is attempting to instantiate an orb from a class loader higher
up in the hierarchy. Also if you have overridden the RMI settings
you will have to put the yoko classes in the rmi-naming plan since
that plan starts an RMI registry.
-dain
On Sep 6, 2006, at 11:28 AM, Aaron Mulder wrote:
> It may be that the ORBConfigAdapter is included in the class path of
> one of the parents of j2ee-corba, but the Yoko classes are only
> included in j2ee-corba... So in other words, the ORBConfigAdapter may
> be loaded from a higher CL than Yoko, so it may not be able to see
> Yoko classes unless you move Yoko up or move ORBConfigAdapter down.
>
> Thanks,
> Aaron
>
> On 9/6/06, Rick McGuire <ri...@gmail.com> wrote:
>> I'm working my way toward getting a full Geronimo build with the Yoko
>> ORB, which means a lot of changes to the various plans. In the
>> client-corba plan, I have the following GBean definition:
>>
>> <gbean name="ORBConfigAdapter"
>> class="org.openejb.corba.yoko.ORBConfigAdapterGBean"/>
>>
>> The ORBConfigAdapterGBean is a new bean that encapsulates the
>> configuration knowledge of the target ORB implementation. As you
>> might
>> expect, this has a few references to Yoko-specific classes. While
>> trying to build this config, I got a NoClassDefFoundError trying
>> to load
>> one of the Yoko classes. Obviously a dependency problem, so I
>> added the
>> following dependency to the client-corba/pom.xml file:
>>
>> <dependency>
>> <groupId>org.apache.yoko</groupId>
>> <artifactId>yoko-core</artifactId>
>> </dependency>
>>
>> Problem solved, the config built properly and the build sped along
>> until
>> it hit the j2ee-corba config. This config has the same
>> ORBConfigAdapter
>> GBean defined. Not surprisingly, I got the same NoClassDefFoundError
>> for the same class when trying to retrieve the GBeanInfo. Doh! This
>> should be the same fix as the client-corba problem, so I added the
>> same
>> dependency lines to j2ee-corba/pom.xml. This time, the error does
>> NOT
>> go away :-( The dependency is showing up in the generated
>> target/plan/plan.xml file with the correct version number, the
>> NoClassDefFoundError seems to be very persistent. I've run out of
>> ideas
>> on how to fix or debug this problem. Any suggestions on what
>> might be
>> going wrong?
>>
>> Rick
>>
Re: Head-scratching dependency problem
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
It may be that the ORBConfigAdapter is included in the class path of
one of the parents of j2ee-corba, but the Yoko classes are only
included in j2ee-corba... So in other words, the ORBConfigAdapter may
be loaded from a higher CL than Yoko, so it may not be able to see
Yoko classes unless you move Yoko up or move ORBConfigAdapter down.
Thanks,
Aaron
On 9/6/06, Rick McGuire <ri...@gmail.com> wrote:
> I'm working my way toward getting a full Geronimo build with the Yoko
> ORB, which means a lot of changes to the various plans. In the
> client-corba plan, I have the following GBean definition:
>
> <gbean name="ORBConfigAdapter"
> class="org.openejb.corba.yoko.ORBConfigAdapterGBean"/>
>
> The ORBConfigAdapterGBean is a new bean that encapsulates the
> configuration knowledge of the target ORB implementation. As you might
> expect, this has a few references to Yoko-specific classes. While
> trying to build this config, I got a NoClassDefFoundError trying to load
> one of the Yoko classes. Obviously a dependency problem, so I added the
> following dependency to the client-corba/pom.xml file:
>
> <dependency>
> <groupId>org.apache.yoko</groupId>
> <artifactId>yoko-core</artifactId>
> </dependency>
>
> Problem solved, the config built properly and the build sped along until
> it hit the j2ee-corba config. This config has the same ORBConfigAdapter
> GBean defined. Not surprisingly, I got the same NoClassDefFoundError
> for the same class when trying to retrieve the GBeanInfo. Doh! This
> should be the same fix as the client-corba problem, so I added the same
> dependency lines to j2ee-corba/pom.xml. This time, the error does NOT
> go away :-( The dependency is showing up in the generated
> target/plan/plan.xml file with the correct version number, the
> NoClassDefFoundError seems to be very persistent. I've run out of ideas
> on how to fix or debug this problem. Any suggestions on what might be
> going wrong?
>
> Rick
>