On 9/8/09 8:56, Cornelius, Martin (DWBI) wrote:
Karl Pauls wrote
Well, it looks to me (but I might be wrong) that you are making a
mistake by setting the Thread context classloader to the classloader
of the jacorb class. Why this is going wrong is hard to say with the
small amount of information you are sharing with us.
If I do NOT set the thread context classloader, the method ORB.init() returns
this exception:
org.omg.CORBA.INITIALIZE: Could not instantiate ORB implementation:
org.jacorb.orb.ORB
The reason for this is, that org.omg.CORBA.ORB.init() - the version of sun and
the version contained in JacORB as well - internally use the thread context
class loader to load the orb implementation class (the name of this class is
read from system property org.omg.CORBA.ORBClass). The default thread context
class loader in Felix is the application class loader, and this classloader
cannot find the jacorb classes. Inside JacORB, the thread context classloader
is used in many places when classes are loaded by name. Thus, it seems
necessary to set the thread context classloader to a bundle classloader in any
thread that uses the jacorb libraries. My experiments so far show this is
indeed the case. As far as I understand, the possibility to pass a classloader
down into a library via Thread.setContextClassLoader was primarily created to
solve such class loading problems.
Could you share the manifests of the bundles with us?
Of course, but i'm not sure if attachments will go through to the list
subscribers, hopefully they do. I will also attach the .bnd file I used to
'wrap' the jacorb.jar into a bundle. Please note that jacorb uses several other
jars that are contained in the jacorb distribution. Some of these jars are
already bundles, but some are not, and I had to 'bundelize' them as well.
Meanwhile, I have got some more information on the topic from François
Fornaciari, who has also tried to bundelize jacorb about 2 years ago. He
finally gave up due to class loading issues, and used the sun orb instead.
I'm quite sure now, that the problem is caused by this fact: JacORB redefines a
great part of the org.omg.* packages, but unfortunately NOT ALL of them. As the
JacORB versions of the packages contain more classes than the sun packages, it
is not possible to 'wire' everything under org.omg to the sun versions of the
packages. (what is the standard setting of felix, when property
org.osgi.framework.system.packages is not defined)
Thus, I tried to 'wire' everything under org.omg to the jacorb Bundle, but that
also fails, because some of the sun classes under omg.org referenced by the
bundle are not contained in the bundle.
I fiddled around a lot with various settings of
org.osgi.framework.system.packages, but finally I always encountered verify
errors, linkage errors, or class incompatibility errors. Obviously it's not
possible to completely prevent that classes under org.omg are sometimes loaded
from rt.jar (via the system class loader), and sometimes (via the bundle
classloader) from the jacorb-bundle. Here is an example, that looks suspicious
to me:
Class org.jacorb.orb.Reference, which is heavily used in JacORB, extends
javax.rmi.CORBA.Stub. javax.rmi.CORBA.Stub IS NOT contained in Jacorb, but
extends org.omg.CORBA_2_3.portable.ObjectImpl, which again IS contained in
Jacorb. org.omg.CORBA_2_3.portable.ObjectImpl extends
org.omg.CORBA.portable.ObjectImpl, which implements org.omg.CORBA.Object. Thus,
ths type hiearchy looks like this:
org.jacorb.orb.Reference // only inside bundle
<extends>
javax.rmi.CORBA.Stub // only inside rt.jar
<extends>
org.omg.CORBA_2_3.portable.ObjectImpl // inside bundle and rt.jar
<implements>
org.omg.CORBA.Object // inside bundle and rt.jar
When running code that uses the jacorb bundle, at some point I get this
exception:
java.lang.IncompatibleClassChangeError: Class org.jacorb.orb.Reference does
not implement the requested interface org.omg.CORBA.Object
I suspect the following happens here:
When class org.jacorb.orb.Reference is loaded (from the bundle by the bundle
classloader), parent class javax.rmi.CORBA.Stub must be loaded. As this class
is not in the bundle, it is loaded by the system classloader from rt.jar. The
base classes of javax.rmi.CORBA.Stub are then also loaded from rt.jar by the
system classloader, thus org.jacorb.orb.Reference implements the version of
org.omg.CORBA.Object loaded from rt.jar.
Yes, that is what is happening. There is actually a hidden "uses"
constraint here between the JRE packages. As you have observed, you
cannot tease JRE classes apart, since they will never load dependent
classes from a bundle. Thus you are using two different versions of the
OMG classes. You literally have to replace everything in the JRE that
touches these that you are using.
If an object reference to org.omg.CORBA.Object is created 'directly' in the
bundle code, it will refer to the version of org.omg.CORBA.Object from the
jacorb bundle. Thus, an instance of org.jacorb.orb.Reference is not assignable
to it.
AFAIKS, the only solution to this problem is to make jacorb 'self-contained',
i.e., put a copy of javax.rmi.CORBA.Stub into the jacorb bundle. Of course,
there may be other classes that are missing...
Yep. Sucks.
-> richard
Regards, Martin
************************************************
The information contained in, or attached to, this e-mail, may contain
confidential information and is intended solely for the use of the individual
or entity to whom they are addressed and may be subject to legal privilege. If
you have received this e-mail in error you should notify the sender immediately
by reply e-mail, delete the message from your system and notify your system
manager. Please do not copy it for any purpose, or disclose its contents to
any other person. The views or opinions presented in this e-mail are solely
those of the author and do not necessarily represent those of the company. The
recipient should check this e-mail and any attachments for the presence of
viruses. The company accepts no liability for any damage caused, directly or
indirectly, by any virus transmitted in this email.
************************************************
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
