You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Cornelius, Martin (DWBI)" <Ma...@smiths-heimann.com> on 2009/09/07 13:02:27 UTC
Bundelizing Jacorb -- getting screwed
Hi all,
Trying to bundelize the free CORBA implementation I'm eventually getting
screwed up.
I encountered some problems, which I could solve:
1.) Jacorb defines it's own versions of nearly all system packages under
org.omg. Thus, I had to define my own version of property
org.osgi.framework.system.packages, which omits all this packages.
2.) To instantiate the orb in a BundleActivator.start() method. I had to
insert this code befpor calling ORB.init():
Thread.currentThread().setContextClassLoader(
org.jacorb.orb.ORB.class.getClassLoader());
Noew I can instantiate the orb, however, when I try to use it, i.e.,
create a CORBA object from an IOR, I get this exception:
java.lang.VerifyError: (class: org/jacorb/orb/Delegate, method:
getReference signature:
(Lorg/jacorb/poa/POA;)Lorg/omg/CORBA/portable/ObjectImpl;) Incompatible
object argument for function call
I have googled a lot to find a solution for this problem, and found that
somebody else had exactly the samee problem about 2 years ago and asked
for help on a mailing list. However, as far as i could figure out no
solution was found at that time.
Many thanks for any hibts in advance !!!
Martin Cornelius
************************************************
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Using JacORB as OSGi Bundle succeded (was: Bundelizing Jacorb
-- getting screwed)
Posted by rahushar <ra...@ciena.com>.
Hello Martin,
I am going through the same problem that you faced 4 yrs ago :-). I have to
use jacorb.jar in my OSGi bundle. However after bundeling, I am getting
Verify error and perhaps for the same reason as you mentioned in your post
"JacORB as OSGi Bundle succeded (was: Bundelizing Jacorb -- getting
screwed)".
Here is the error that is thrown:
Bad type on operand stack
Exception Details:
Location:
org/jacorb/orb/Delegate.getReference(Lorg/jacorb/poa/POA;)Lorg/omg/CORBA/portable/ObjectImpl;
@42: invokevirtual
Reason:
Type 'org/jacorb/orb/Reference' (current frame, stack[0]) is not
assignable to 'org/omg/CORBA/portable/ObjectImpl'
Current Frame:
bci: @42
flags: { }
locals: { 'org/jacorb/orb/Delegate', 'org/jacorb/poa/POA',
'java/lang/String', 'org/jacorb/orb/Reference' }
stack: { 'org/jacorb/orb/Reference', 'org/jacorb/orb/Delegate' }
I am using Jacorb-3.4 with JRE-7 and Equinox as the OSGi platform.
Should I go ahead and re-bundle Jacorb as you suggested? Or is there a
better alternative where-in we can also use RMI-IIOP as well?
Any advise will be appreciated.
Regards,
Rahul
--
View this message in context: http://apache-felix.18485.x6.nabble.com/Bundelizing-Jacorb-getting-screwed-tp4843264p5007392.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Using JacORB as OSGi Bundle succeded
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Great! Thanks for reporting back.
-> richard
On 9/9/09 8:19, Cornelius, Martin (DWBI) wrote:
> Richard S. Hall wrote
>
>
>> Martin Cornelius wrote
>> 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.
>>
> Just putting javax.rmi.CORBA.Stub into the jacorb bundle is no solution, because javax.rmi.CORBA.Stub itself depends on tons of sun.* and com.sun* classes 8-(
>
> However, there is a simple solution, albeit it requires rebuilding jacorb: Just specify -Dno-rmi=true when building jacorb. This results in a jacorb.jar, where org.jacorb.orb.Reference directly extends org.omg.CORBA.portable.ObjectImpl. The drawback of this might be, that the resulting jacorb does not support rmi-iiop, but that's not needed for 'normal' CORBA communication.
>
> After bundelization of the jacorb.jar with bnd, the resulting bundle still has a dependeny to package javax.rmi.CORBA, but this one doesn't harm. It is due to usage of class javax.rmi.CORBA.ClassDesc in org.jacorb.orb.CDROutputStream. As javax.rmi.CORBA.ClassDesc has no dependencies into org.omg.*, this is OK.
>
> Additionally, I ripped package org.omg.SendingContext out of the runtime (rt.jar) and added it to jacorb.jar. This might be needed because class org.omg.SendingContext.RunTime also depends on org.omg.CORBA.Object.
>
> With the bundle produced from this jacorb.jar (using bnd), i was able to run jacorb and an application that uses it as felix bundles - without having jacorb on the classpath. Hurrayyyyy, eventually this cost me about 2 weeks of work !
>
> If anybody is still interested in a detailed HOWTO use JacORB-2.3.1 as felix bundle, just ask...
>
> 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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Using JacORB as OSGi Bundle succeded (was: Bundelizing Jacorb -- getting screwed)
Posted by "Cornelius, Martin (DWBI)" <Ma...@smiths-heimann.com>.
Richard S. Hall wrote
> Martin Cornelius wrote
> 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.
Just putting javax.rmi.CORBA.Stub into the jacorb bundle is no solution, because javax.rmi.CORBA.Stub itself depends on tons of sun.* and com.sun* classes 8-(
However, there is a simple solution, albeit it requires rebuilding jacorb: Just specify -Dno-rmi=true when building jacorb. This results in a jacorb.jar, where org.jacorb.orb.Reference directly extends org.omg.CORBA.portable.ObjectImpl. The drawback of this might be, that the resulting jacorb does not support rmi-iiop, but that's not needed for 'normal' CORBA communication.
After bundelization of the jacorb.jar with bnd, the resulting bundle still has a dependeny to package javax.rmi.CORBA, but this one doesn't harm. It is due to usage of class javax.rmi.CORBA.ClassDesc in org.jacorb.orb.CDROutputStream. As javax.rmi.CORBA.ClassDesc has no dependencies into org.omg.*, this is OK.
Additionally, I ripped package org.omg.SendingContext out of the runtime (rt.jar) and added it to jacorb.jar. This might be needed because class org.omg.SendingContext.RunTime also depends on org.omg.CORBA.Object.
With the bundle produced from this jacorb.jar (using bnd), i was able to run jacorb and an application that uses it as felix bundles - without having jacorb on the classpath. Hurrayyyyy, eventually this cost me about 2 weeks of work !
If anybody is still interested in a detailed HOWTO use JacORB-2.3.1 as felix bundle, just ask...
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AW: Bundelizing Jacorb -- getting screwed
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
AW: Bundelizing Jacorb -- getting screwed
Posted by "Cornelius, Martin (DWBI)" <Ma...@smiths-heimann.com>.
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.
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...
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.
************************************************
Re: Bundelizing Jacorb -- getting screwed
Posted by Karl Pauls <ka...@gmail.com>.
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. Could you share
the manifests of the bundles with us?
regards,
Karl
On Mon, Sep 7, 2009 at 7:52 PM, Cornelius, Martin
(DWBI)<Ma...@smiths-heimann.com> wrote:
>
>
>
> This problem seems to occur under various circumstances, when jacorb is
> used in an embedded way. Meanwhile I found lots of reports of the
> problem, but obviously no one solved it so far. I guess it is some very
> subtle class loading problem.
>
> Perhaps one could find the source of the problem, if one knew which
> classes were loaded from which location buy which class-loader.
>
> Is there a way to get this information from felix ?
>
> Again, many thanks in advance for any help
>
> 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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
AW: Bundelizing Jacorb -- getting screwed
Posted by "Cornelius, Martin (DWBI)" <Ma...@smiths-heimann.com>.
This problem seems to occur under various circumstances, when jacorb is
used in an embedded way. Meanwhile I found lots of reports of the
problem, but obviously no one solved it so far. I guess it is some very
subtle class loading problem.
Perhaps one could find the source of the problem, if one knew which
classes were loaded from which location buy which class-loader.
Is there a way to get this information from felix ?
Again, many thanks in advance for any help
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org