LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
|
View:
New views
15 Messages
—
Rating Filter:
Alert me
|
 |
LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Marina Vatkina
::
Rate this Message:
Team,
Does anybody know what can cause this type of a LinkageError: Caused by: java.lang.VerifyError: (class: org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: initORB signature: (Ljava/util/Properties;)V) Bad type in putfield/putstatic at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) I see this error if I remove org.omg.CORBA package (only it, not its subpackages) from the glassfishv3/glassfish/osgi/felix/conf/config.properties (because it's available in the glassfish-corba-omgapi module) and then try to deploy an app with remote EJBs (i.e. force orb integration modules to be loaded). The same error happens on server restart if I first deploy the app, then modify the felix/conf/config.properties file. Googling for this error brings cases when 2 versions of the same class was present in 2 jars. But GlassFishORBManager is there in only one. Or a jdk 1.4 bug where you downcast the result to one of the interfaces (String to Clonable), which a) had been fixed back then and b) doesn't seem to be the case here as well :(. It doesn't make a difference whether I start GF via 'java -jar' or asadmin. Any ideas are greatly appreciated. thank you, -marina --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Sahoo
::
Rate this Message:
I think I know what's happening here. I am a bit surprised that it
didn't result in a "loader constraint violation," which is also a LinkageError, but any way, I think I have an explanation for this linkage error. /javap -classpath orb-iiop.jar -p -c org.glassfish.enterprise.iiop.impl.GlassFishORBManager /shows the following bytecodes: * 495: invokestatic #114; //Method com/sun/corba/ee/spi/osgi/ORBFactory.create:([Ljava/lang/String;Ljava/util/Properties;Z)Lcom/sun/corba/e e/spi/orb/ORB; 498: putfield #2; //Field orb:Lorg/omg/CORBA/ORB; * Basically, it translates to something like this: org.omg.CORBA.ORB something = com.sun.corba.ee.spi.osgi.ORBFactory.create(properties); com.sun.corba.ee.spi.osgi.ORBFactory.create(Properties) returns com.sun.corba.ee.spi.orb.ORB, which definitely extends org.omg.CORBA.ORB for the code to compile. So, let's inspect the hierarchy of this class: (*->* means extends and within bracket the jar that supplies the class is mentioned as well. Each jar has a separate class loader) com.sun.corba.ee.spi.orb.ORB (/glassfish-corba-orb.jar/) -> com.sun.corba.ee.org.omg.CORBA.ORB (/glassfish-corba-omgapi.jar/) -> org.omg.CORBA_2_3.ORB (/JDK's rt.jar/) -> org.omg.CORBA.ORB (/JDK's rt.jar/) Note a *duplication* of class in the runtime: glassfish-corba-omgapi.jar exports org.omg.CORBA package and has org.omg.CORBA.ORB.class in it. JDK's rt.jar also has org.omg.CORBA.ORB.class. Since you *removed* org.omg.CORBA from system.packages list, GlassFishORBManager, which is loaded from org-iiop.jar module, gets org.omg.CORBA.ORB.class from glassfish-corba-omgapi.jar. As a result, the simple assignment is looking like this: *org.omg.CORBA.ORB(glassfish-corba-omgapi.jar) = org.omg.CORBA.ORB (JDK's rt.jar)* As you can see, they are two different types and hence the VerificationError. There are several ways to *solve* it. 1. If you add a *bootdelegation* property for org.omg.CORBA package, then everyone will see org.omg.CORBA.ORB(JDK's rt.jar) and that will address the issue. Although this solution looks simple, it is not preferred, as it is a violation of modularity principle. More over, it leads to split packages which can lead to other issues at runtime like access violation of package scoped objects. 2. If you remove all the org.omg CORBA related packages (including org.omg.CORBA_2_3) from system packages list and ensure that they are exported by glassfish-corba-omgapi bundle, then also every one will see one version of classes and the problem will be solved. There is an assumption here that no other JDK class other than the CORBA implementation has direct reference to these packages. 3. If we can put glassfish-corba-omgapi.jar in one of the java.endorsed.dirs and add all the new packages to system.packages list, then also everyone see one consistent version of classes. Since we can't assume we are using jre/lib/endorsed, this has the disadvantage of requiring user to specify -Djava.endorsed.dirs in command line, something which does not fly with "java -jar glassfish.jar" style invocation. For now, I think we can start with option #2 and if we face any issues, we can go to #1. Now let's see why the error was so cryptic in an OSGi environment. After all, OSGi is supposed to give us more helpful errors. The problem is our system packages are exported without any "uses" clause. "uses" clause plays a vital role in package resolution and correct specification of uses attribute might have given us a better error stating the class space was not consistent. Hope that helps, Thanks, Sahoo Marina Vatkina wrote: > Team, > > Does anybody know what can cause this type of a LinkageError: > > Caused by: java.lang.VerifyError: (class: > org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: > initORB signature: (Ljava/util/Properties;)V) Bad type in > putfield/putstatic > at > org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) > > at > com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) > > > I see this error if I remove org.omg.CORBA package (only it, not its > subpackages) from the > glassfishv3/glassfish/osgi/felix/conf/config.properties (because it's > available in the glassfish-corba-omgapi module) and then try to deploy > an app with remote EJBs (i.e. force orb integration modules to be > loaded). The same error happens on server restart if I first deploy > the app, then modify the felix/conf/config.properties file. > > Googling for this error brings cases when 2 versions of the same class > was present in 2 jars. But GlassFishORBManager is there in only one. > Or a jdk 1.4 bug where you downcast the result to one of the > interfaces (String to Clonable), which a) had been fixed back then and > b) doesn't seem to be the case here as well :(. > > It doesn't make a difference whether I start GF via 'java -jar' or > asadmin. > > Any ideas are greatly appreciated. > > thank you, > -marina > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Richard S. Hall
::
Rate this Message:
On 5/27/09 4:19 AM, Sahoo wrote:
> Now let's see why the error was so cryptic in an OSGi environment. > After all, OSGi is supposed to give us more helpful errors. The > problem is our system packages are exported without any "uses" clause. > "uses" clause plays a vital role in package resolution and correct > specification of uses attribute might have given us a better error > stating the class space was not consistent. Yes, you are correct. The system packages for the JRE do not correctly express "uses" constraints. Not sure what we can do here. I wonder if BND could generate that information. I wonder if it would have any negative consequences. It would be interesting information, nonetheless. -> richard > > Hope that helps, > Thanks, > Sahoo > > Marina Vatkina wrote: >> Team, >> >> Does anybody know what can cause this type of a LinkageError: >> >> Caused by: java.lang.VerifyError: (class: >> org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: >> initORB signature: (Ljava/util/Properties;)V) Bad type in >> putfield/putstatic >> at >> org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) >> >> at >> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) >> >> >> I see this error if I remove org.omg.CORBA package (only it, not its >> subpackages) from the >> glassfishv3/glassfish/osgi/felix/conf/config.properties (because it's >> available in the glassfish-corba-omgapi module) and then try to >> deploy an app with remote EJBs (i.e. force orb integration modules to >> be loaded). The same error happens on server restart if I first >> deploy the app, then modify the felix/conf/config.properties file. >> >> Googling for this error brings cases when 2 versions of the same >> class was present in 2 jars. But GlassFishORBManager is there in only >> one. Or a jdk 1.4 bug where you downcast the result to one of the >> interfaces (String to Clonable), which a) had been fixed back then >> and b) doesn't seem to be the case here as well :(. >> >> It doesn't make a difference whether I start GF via 'java -jar' or >> asadmin. >> >> Any ideas are greatly appreciated. >> >> thank you, >> -marina >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Richard S. Hall
::
Rate this Message:
I played around with BND to see if I could generate this information. I
did see the following "used by" relationships, which are correctly
captured in "uses" constraints:
-> richard On 5/27/09 10:20 AM, Richard S. Hall wrote: On 5/27/09 4:19 AM, Sahoo wrote: |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Sahoo
::
Rate this Message:
This is good information. This can be used to arrive at a proper
solution. I am inclined to say solution #2 (see my previous email) will require us to package a lot of classes in OSGi bundles, because there will be other JDK packages which depends on this set of packages and all of them have to be repackaged. It may not be legal to do so. Even if it is legal, it may just be too heavyweight a solution. So, #1 may be only viable solution. Do you agree? Thanks, Sahoo Richard S. Hall wrote: > I played around with BND to see if I could generate this information. > I did see the following "used by" relationships, which are correctly > captured in "uses" constraints: > > * org.omg.CORBA used by: > o javax.management.remote.rmi > o javax.rmi > o javax.rmi.CORBA > o org.omg.CORBA.DynAnyPackage > o org.omg.CORBA.ORBPackage > o org.omg.CORBA.TypeCodePackage > o org.omg.CORBA.portable > o org.omg.CORBA_2_3 > o org.omg.CORBA_2_3.portable > o org.omg.CosNaming > o org.omg.CosNaming.NamingContextExtPackage > o org.omg.CosNaming.NamingContextPackage > o org.omg.Dynamic > o org.omg.DynamicAny > o org.omg.DynamicAny.DynAnyFactoryPackage > o org.omg.DynamicAny.DynAnyPackage > o org.omg.IOP > o org.omg.IOP.CodecFactoryPackage > o org.omg.IOP.CodecPackage > o org.omg.Messaging > o org.omg.PortableInterceptor > o org.omg.PortableInterceptor.ORBInitInfoPackage > o org.omg.PortableServer > o org.omg.PortableServer.CurrentPackage > o org.omg.PortableServer.POAManagerPackage > o org.omg.PortableServer.POAPackage > o org.omg.PortableServer.ServantLocatorPackage > o org.omg.PortableServer.portable > o org.omg.SendingContext > o org.omg.stub.javax.management.remote.rmi > > I did this on a Mac, so it is not necessarily clear if this > information is universal, but it could potentially work. > > -> richard > > On 5/27/09 10:20 AM, Richard S. Hall wrote: >> On 5/27/09 4:19 AM, Sahoo wrote: >>> Now let's see why the error was so cryptic in an OSGi environment. >>> After all, OSGi is supposed to give us more helpful errors. The >>> problem is our system packages are exported without any "uses" >>> clause. "uses" clause plays a vital role in package resolution and >>> correct specification of uses attribute might have given us a better >>> error stating the class space was not consistent. >> >> Yes, you are correct. The system packages for the JRE do not >> correctly express "uses" constraints. Not sure what we can do here. I >> wonder if BND could generate that information. I wonder if it would >> have any negative consequences. It would be interesting information, >> nonetheless. >> >> -> richard >> >>> >>> Hope that helps, >>> Thanks, >>> Sahoo >>> >>> Marina Vatkina wrote: >>>> Team, >>>> >>>> Does anybody know what can cause this type of a LinkageError: >>>> >>>> Caused by: java.lang.VerifyError: (class: >>>> org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: >>>> initORB signature: (Ljava/util/Properties;)V) Bad type in >>>> putfield/putstatic >>>> at >>>> org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) >>>> >>>> at >>>> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) >>>> >>>> >>>> >>>> I see this error if I remove org.omg.CORBA package (only it, not >>>> its subpackages) from the >>>> glassfishv3/glassfish/osgi/felix/conf/config.properties (because >>>> it's available in the glassfish-corba-omgapi module) and then try >>>> to deploy an app with remote EJBs (i.e. force orb integration >>>> modules to be loaded). The same error happens on server restart if >>>> I first deploy the app, then modify the >>>> felix/conf/config.properties file. >>>> >>>> Googling for this error brings cases when 2 versions of the same >>>> class was present in 2 jars. But GlassFishORBManager is there in >>>> only one. Or a jdk 1.4 bug where you downcast the result to one of >>>> the interfaces (String to Clonable), which a) had been fixed back >>>> then and b) doesn't seem to be the case here as well :(. >>>> >>>> It doesn't make a difference whether I start GF via 'java -jar' or >>>> asadmin. >>>> >>>> Any ideas are greatly appreciated. >>>> >>>> thank you, >>>> -marina >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Richard S. Hall
::
Rate this Message:
On 5/27/09 12:31 PM, Sahoo wrote:
> This is good information. This can be used to arrive at a proper > solution. I am inclined to say solution #2 (see my previous email) > will require us to package a lot of classes in OSGi bundles, because > there will be other JDK packages which depends on this set of packages > and all of them have to be repackaged. It may not be legal to do so. > Even if it is legal, it may just be too heavyweight a solution. So, #1 > may be only viable solution. Do you agree? I think the answer depends, but ultimately you may be correct. However, if we can adopt boot delegation as a solution, then it seems to be equivalent of saying that it is not necessary for any other bundle to export what we are boot delegating, since everyone will use the JRE package. If that is true, then we should be able to remove the duplicate package from the exporting bundle and just export it from the system bundle from which every bundle will import it, no? -> richard p.s. I have the "uses" information for the JRE packages if you want me to send it to you. > > Thanks, > Sahoo > > Richard S. Hall wrote: >> I played around with BND to see if I could generate this information. >> I did see the following "used by" relationships, which are correctly >> captured in "uses" constraints: >> >> * org.omg.CORBA used by: >> o javax.management.remote.rmi >> o javax.rmi >> o javax.rmi.CORBA >> o org.omg.CORBA.DynAnyPackage >> o org.omg.CORBA.ORBPackage >> o org.omg.CORBA.TypeCodePackage >> o org.omg.CORBA.portable >> o org.omg.CORBA_2_3 >> o org.omg.CORBA_2_3.portable >> o org.omg.CosNaming >> o org.omg.CosNaming.NamingContextExtPackage >> o org.omg.CosNaming.NamingContextPackage >> o org.omg.Dynamic >> o org.omg.DynamicAny >> o org.omg.DynamicAny.DynAnyFactoryPackage >> o org.omg.DynamicAny.DynAnyPackage >> o org.omg.IOP >> o org.omg.IOP.CodecFactoryPackage >> o org.omg.IOP.CodecPackage >> o org.omg.Messaging >> o org.omg.PortableInterceptor >> o org.omg.PortableInterceptor.ORBInitInfoPackage >> o org.omg.PortableServer >> o org.omg.PortableServer.CurrentPackage >> o org.omg.PortableServer.POAManagerPackage >> o org.omg.PortableServer.POAPackage >> o org.omg.PortableServer.ServantLocatorPackage >> o org.omg.PortableServer.portable >> o org.omg.SendingContext >> o org.omg.stub.javax.management.remote.rmi >> >> I did this on a Mac, so it is not necessarily clear if this >> information is universal, but it could potentially work. >> >> -> richard >> >> On 5/27/09 10:20 AM, Richard S. Hall wrote: >>> On 5/27/09 4:19 AM, Sahoo wrote: >>>> Now let's see why the error was so cryptic in an OSGi environment. >>>> After all, OSGi is supposed to give us more helpful errors. The >>>> problem is our system packages are exported without any "uses" >>>> clause. "uses" clause plays a vital role in package resolution and >>>> correct specification of uses attribute might have given us a >>>> better error stating the class space was not consistent. >>> >>> Yes, you are correct. The system packages for the JRE do not >>> correctly express "uses" constraints. Not sure what we can do here. >>> I wonder if BND could generate that information. I wonder if it >>> would have any negative consequences. It would be interesting >>> information, nonetheless. >>> >>> -> richard >>> >>>> >>>> Hope that helps, >>>> Thanks, >>>> Sahoo >>>> >>>> Marina Vatkina wrote: >>>>> Team, >>>>> >>>>> Does anybody know what can cause this type of a LinkageError: >>>>> >>>>> Caused by: java.lang.VerifyError: (class: >>>>> org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: >>>>> initORB signature: (Ljava/util/Properties;)V) Bad type in >>>>> putfield/putstatic >>>>> at >>>>> org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) >>>>> >>>>> at >>>>> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) >>>>> >>>>> >>>>> >>>>> I see this error if I remove org.omg.CORBA package (only it, not >>>>> its subpackages) from the >>>>> glassfishv3/glassfish/osgi/felix/conf/config.properties (because >>>>> it's available in the glassfish-corba-omgapi module) and then try >>>>> to deploy an app with remote EJBs (i.e. force orb integration >>>>> modules to be loaded). The same error happens on server restart if >>>>> I first deploy the app, then modify the >>>>> felix/conf/config.properties file. >>>>> >>>>> Googling for this error brings cases when 2 versions of the same >>>>> class was present in 2 jars. But GlassFishORBManager is there in >>>>> only one. Or a jdk 1.4 bug where you downcast the result to one of >>>>> the interfaces (String to Clonable), which a) had been fixed back >>>>> then and b) doesn't seem to be the case here as well :(. >>>>> >>>>> It doesn't make a difference whether I start GF via 'java -jar' or >>>>> asadmin. >>>>> >>>>> Any ideas are greatly appreciated. >>>>> >>>>> thank you, >>>>> -marina >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Sahoo
::
Rate this Message:
Richard S. Hall wrote:
> On 5/27/09 12:31 PM, Sahoo wrote: >> This is good information. This can be used to arrive at a proper >> solution. I am inclined to say solution #2 (see my previous email) >> will require us to package a lot of classes in OSGi bundles, because >> there will be other JDK packages which depends on this set of >> packages and all of them have to be repackaged. It may not be legal >> to do so. Even if it is legal, it may just be too heavyweight a >> solution. So, #1 may be only viable solution. Do you agree? > > I think the answer depends, but ultimately you may be correct. > > However, if we can adopt boot delegation as a solution, then it seems > to be equivalent of saying that it is not necessary for any other > bundle to export what we are boot delegating, since everyone will use > the JRE package. If that is true, then we should be able to remove the > duplicate package from the exporting bundle and just export it from > the system bundle from which every bundle will import it, no? > issue. As I mentioned somewhere in that email, JDK contains partial list of classes for some of those packages. So, we need to have another bundle export those packages, so that when bootdelegation fails to locate one of those extra classes, it can be found traversing Import-Package wiring. We have the same issue with javax.transaction. javas.sql, which is coming from rt.jar, depends on javax.transaction, but rt.jar has only a few of the javax.transaction classes. So, we bootdelegate javax.transaction in addition to having our own javax.transaction bundle which has all the classes. Thanks, Sahoo --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Richard S. Hall
::
Rate this Message:
On 5/27/09 1:29 PM, Sahoo wrote:
> Richard S. Hall wrote: >> On 5/27/09 12:31 PM, Sahoo wrote: >>> This is good information. This can be used to arrive at a proper >>> solution. I am inclined to say solution #2 (see my previous email) >>> will require us to package a lot of classes in OSGi bundles, because >>> there will be other JDK packages which depends on this set of >>> packages and all of them have to be repackaged. It may not be legal >>> to do so. Even if it is legal, it may just be too heavyweight a >>> solution. So, #1 may be only viable solution. Do you agree? >> >> I think the answer depends, but ultimately you may be correct. >> >> However, if we can adopt boot delegation as a solution, then it seems >> to be equivalent of saying that it is not necessary for any other >> bundle to export what we are boot delegating, since everyone will use >> the JRE package. If that is true, then we should be able to remove >> the duplicate package from the exporting bundle and just export it >> from the system bundle from which every bundle will import it, no? >> > Not really unless I am misunderstanding you. It's an ugly > split-package issue. As I mentioned somewhere in that email, JDK > contains partial list of classes for some of those packages. So, we > need to have another bundle export those packages, so that when > bootdelegation fails to locate one of those extra classes, it can be > found traversing Import-Package wiring. > > We have the same issue with javax.transaction. javas.sql, which is > coming from rt.jar, depends on javax.transaction, but rt.jar has only > a few of the javax.transaction classes. So, we bootdelegate > javax.transaction in addition to having our own javax.transaction > bundle which has all the classes. Ok, so we are using boot delegation to create the union of the partial JRE package with the bundle exported package, essentially. Yes, I don't see another way to deal with that. The proper approach would be to replace the JRE packages completely, since they appear to be faulty (since they are incomplete); however, I agree that this would likely entail re-packaging much more than the offending package due to "uses" constraints. -> richard --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Marina Vatkina
::
Rate this Message:
Ken,
Is it possible to remove duplicate classes from the glassfish-corba-xxx modules? thanks, -marina Sahoo wrote: > I think I know what's happening here. I am a bit surprised that it > didn't result in a "loader constraint violation," which is also a > LinkageError, but any way, I think I have an explanation for this > linkage error. > > /javap -classpath orb-iiop.jar -p -c > org.glassfish.enterprise.iiop.impl.GlassFishORBManager > /shows the following bytecodes: > * 495: invokestatic #114; //Method > com/sun/corba/ee/spi/osgi/ORBFactory.create:([Ljava/lang/String;Ljava/util/Properties;Z)Lcom/sun/corba/e > > e/spi/orb/ORB; > 498: putfield #2; //Field orb:Lorg/omg/CORBA/ORB; > * > Basically, it translates to something like this: > org.omg.CORBA.ORB something = > com.sun.corba.ee.spi.osgi.ORBFactory.create(properties); > > com.sun.corba.ee.spi.osgi.ORBFactory.create(Properties) returns > com.sun.corba.ee.spi.orb.ORB, which definitely extends org.omg.CORBA.ORB > for the code to compile. So, let's inspect the hierarchy of this class: > > (*->* means extends and within bracket the jar that supplies the class > is mentioned as well. Each jar has a separate class loader) > > com.sun.corba.ee.spi.orb.ORB (/glassfish-corba-orb.jar/) > -> com.sun.corba.ee.org.omg.CORBA.ORB (/glassfish-corba-omgapi.jar/) > -> org.omg.CORBA_2_3.ORB (/JDK's rt.jar/) > -> org.omg.CORBA.ORB (/JDK's rt.jar/) > > Note a *duplication* of class in the runtime: > glassfish-corba-omgapi.jar exports org.omg.CORBA package and has > org.omg.CORBA.ORB.class in it. > JDK's rt.jar also has org.omg.CORBA.ORB.class. > > Since you *removed* org.omg.CORBA from system.packages list, > GlassFishORBManager, which is loaded from org-iiop.jar module, gets > org.omg.CORBA.ORB.class from glassfish-corba-omgapi.jar. As a result, > the simple assignment is looking like this: > > *org.omg.CORBA.ORB(glassfish-corba-omgapi.jar) = org.omg.CORBA.ORB > (JDK's rt.jar)* > > As you can see, they are two different types and hence the > VerificationError. > > There are several ways to *solve* it. > > 1. If you add a *bootdelegation* property for org.omg.CORBA package, > then everyone will see org.omg.CORBA.ORB(JDK's rt.jar) and that will > address the issue. Although this solution looks simple, it is not > preferred, as it is a violation of modularity principle. More over, it > leads to split packages which can lead to other issues at runtime like > access violation of package scoped objects. > > 2. If you remove all the org.omg CORBA related packages (including > org.omg.CORBA_2_3) from system packages list and ensure that they are > exported by glassfish-corba-omgapi bundle, then also every one will see > one version of classes and the problem will be solved. There is an > assumption here that no other JDK class other than the CORBA > implementation has direct reference to these packages. > > 3. If we can put glassfish-corba-omgapi.jar in one of the > java.endorsed.dirs and add all the new packages to system.packages list, > then also everyone see one consistent version of classes. Since we can't > assume we are using jre/lib/endorsed, this has the disadvantage of > requiring user to specify -Djava.endorsed.dirs in command line, > something which does not fly with "java -jar glassfish.jar" style > invocation. > > For now, I think we can start with option #2 and if we face any issues, > we can go to #1. > > Now let's see why the error was so cryptic in an OSGi environment. After > all, OSGi is supposed to give us more helpful errors. The problem is our > system packages are exported without any "uses" clause. "uses" clause > plays a vital role in package resolution and correct specification of > uses attribute might have given us a better error stating the class > space was not consistent. > > Hope that helps, > Thanks, > Sahoo > > Marina Vatkina wrote: > >> Team, >> >> Does anybody know what can cause this type of a LinkageError: >> >> Caused by: java.lang.VerifyError: (class: >> org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: >> initORB signature: (Ljava/util/Properties;)V) Bad type in >> putfield/putstatic >> at >> org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) >> >> at >> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) >> >> >> I see this error if I remove org.omg.CORBA package (only it, not its >> subpackages) from the >> glassfishv3/glassfish/osgi/felix/conf/config.properties (because it's >> available in the glassfish-corba-omgapi module) and then try to deploy >> an app with remote EJBs (i.e. force orb integration modules to be >> loaded). The same error happens on server restart if I first deploy >> the app, then modify the felix/conf/config.properties file. >> >> Googling for this error brings cases when 2 versions of the same class >> was present in 2 jars. But GlassFishORBManager is there in only one. >> Or a jdk 1.4 bug where you downcast the result to one of the >> interfaces (String to Clonable), which a) had been fixed back then and >> b) doesn't seem to be the case here as well :(. >> >> It doesn't make a difference whether I start GF via 'java -jar' or >> asadmin. >> >> Any ideas are greatly appreciated. >> >> thank you, >> -marina >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Richard S. Hall
::
Rate this Message:
On 5/27/09 4:59 PM, Marina Vatkina wrote: > Ken, > > Is it possible to remove duplicate classes from the > glassfish-corba-xxx modules? The duplicate classes are not really the issue. The issue is that the built-in JRE package is incomplete, so we somehow need to add the missing classes to the package. Unfortunately, we cannot just completely override the JRE package by placing it in a bundle, since other JRE classes use types from the incomplete package ("uses" constraints in OSGi terms). To work around this issue, we need to merge the existing classes in the JRE package with the additional classes being exported by the exporting bundle. The only way we can accomplish something like this in OSGi is to do as Sahoo suggests and use boot delegation to find the existing JRE classes, but have bundles still import the package so they can fall back to the exporting bundle for the missing classes. This will work, since no JRE packages will depend on the missing classes. We just need to make sure the exporting bundle is version compatible with the JRE package. -> richard > > thanks, > -marina > > Sahoo wrote: >> I think I know what's happening here. I am a bit surprised that it >> didn't result in a "loader constraint violation," which is also a >> LinkageError, but any way, I think I have an explanation for this >> linkage error. >> >> /javap -classpath orb-iiop.jar -p -c >> org.glassfish.enterprise.iiop.impl.GlassFishORBManager >> /shows the following bytecodes: >> * 495: invokestatic #114; //Method >> com/sun/corba/ee/spi/osgi/ORBFactory.create:([Ljava/lang/String;Ljava/util/Properties;Z)Lcom/sun/corba/e >> >> e/spi/orb/ORB; >> 498: putfield #2; //Field orb:Lorg/omg/CORBA/ORB; >> * >> Basically, it translates to something like this: >> org.omg.CORBA.ORB something = >> com.sun.corba.ee.spi.osgi.ORBFactory.create(properties); >> >> com.sun.corba.ee.spi.osgi.ORBFactory.create(Properties) returns >> com.sun.corba.ee.spi.orb.ORB, which definitely extends >> org.omg.CORBA.ORB for the code to compile. So, let's inspect the >> hierarchy of this class: >> >> (*->* means extends and within bracket the jar that supplies the >> class is mentioned as well. Each jar has a separate class loader) >> >> com.sun.corba.ee.spi.orb.ORB (/glassfish-corba-orb.jar/) >> -> com.sun.corba.ee.org.omg.CORBA.ORB (/glassfish-corba-omgapi.jar/) >> -> org.omg.CORBA_2_3.ORB (/JDK's rt.jar/) >> -> org.omg.CORBA.ORB (/JDK's rt.jar/) >> >> Note a *duplication* of class in the runtime: >> glassfish-corba-omgapi.jar exports org.omg.CORBA package and has >> org.omg.CORBA.ORB.class in it. >> JDK's rt.jar also has org.omg.CORBA.ORB.class. >> >> Since you *removed* org.omg.CORBA from system.packages list, >> GlassFishORBManager, which is loaded from org-iiop.jar module, gets >> org.omg.CORBA.ORB.class from glassfish-corba-omgapi.jar. As a result, >> the simple assignment is looking like this: >> >> *org.omg.CORBA.ORB(glassfish-corba-omgapi.jar) = org.omg.CORBA.ORB >> (JDK's rt.jar)* >> >> As you can see, they are two different types and hence the >> VerificationError. >> >> There are several ways to *solve* it. >> >> 1. If you add a *bootdelegation* property for org.omg.CORBA package, >> then everyone will see org.omg.CORBA.ORB(JDK's rt.jar) and that will >> address the issue. Although this solution looks simple, it is not >> preferred, as it is a violation of modularity principle. More over, >> it leads to split packages which can lead to other issues at runtime >> like access violation of package scoped objects. >> >> 2. If you remove all the org.omg CORBA related packages (including >> org.omg.CORBA_2_3) from system packages list and ensure that they are >> exported by glassfish-corba-omgapi bundle, then also every one will >> see one version of classes and the problem will be solved. There is >> an assumption here that no other JDK class other than the CORBA >> implementation has direct reference to these packages. >> >> 3. If we can put glassfish-corba-omgapi.jar in one of the >> java.endorsed.dirs and add all the new packages to system.packages >> list, then also everyone see one consistent version of classes. Since >> we can't assume we are using jre/lib/endorsed, this has the >> disadvantage of requiring user to specify -Djava.endorsed.dirs in >> command line, something which does not fly with "java -jar >> glassfish.jar" style invocation. >> >> For now, I think we can start with option #2 and if we face any >> issues, we can go to #1. >> >> Now let's see why the error was so cryptic in an OSGi environment. >> After all, OSGi is supposed to give us more helpful errors. The >> problem is our system packages are exported without any "uses" >> clause. "uses" clause plays a vital role in package resolution and >> correct specification of uses attribute might have given us a better >> error stating the class space was not consistent. >> >> Hope that helps, >> Thanks, >> Sahoo >> >> Marina Vatkina wrote: >> >>> Team, >>> >>> Does anybody know what can cause this type of a LinkageError: >>> >>> Caused by: java.lang.VerifyError: (class: >>> org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: >>> initORB signature: (Ljava/util/Properties;)V) Bad type in >>> putfield/putstatic >>> at >>> org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) >>> >>> at >>> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) >>> >>> >>> >>> I see this error if I remove org.omg.CORBA package (only it, not its >>> subpackages) from the >>> glassfishv3/glassfish/osgi/felix/conf/config.properties (because >>> it's available in the glassfish-corba-omgapi module) and then try to >>> deploy an app with remote EJBs (i.e. force orb integration modules >>> to be loaded). The same error happens on server restart if I first >>> deploy the app, then modify the felix/conf/config.properties file. >>> >>> Googling for this error brings cases when 2 versions of the same >>> class was present in 2 jars. But GlassFishORBManager is there in >>> only one. Or a jdk 1.4 bug where you downcast the result to one of >>> the interfaces (String to Clonable), which a) had been fixed back >>> then and b) doesn't seem to be the case here as well :(. >>> >>> It doesn't make a difference whether I start GF via 'java -jar' or >>> asadmin. >>> >>> Any ideas are greatly appreciated. >>> >>> thank you, >>> -marina >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Marina Vatkina
::
Rate this Message:
Richard S. Hall wrote:
> > > On 5/27/09 4:59 PM, Marina Vatkina wrote: > >> Ken, >> >> Is it possible to remove duplicate classes from the >> glassfish-corba-xxx modules? > > > The duplicate classes are not really the issue. The issue is that the > built-in JRE package is incomplete, so we somehow need to add the > missing classes to the package. If we really need to. Do we have the list of must-haves add-ons? For the org.omg.CORBA package, I know about TSIdentification that Ken Cavanaugh said is possible to be moved to jts module, and the ORB class that exists in 2 locations, JRE and glassfish-corba-omgapi.jar. May be there are more case that I don't know about. If there are, and there is nothing we can do to fix them, yes, we need to work around the problem. Otherwise we might be able to fix it the right way (i.e. remove duplicates and split packages). If we do fall back into the bootdelegation solution, unless it's too time consuming, it would be nice to have the list of those classes that we can't fix otherwise, won't it? thanks, -marina Unfortunately, we cannot just completely > override the JRE package by placing it in a bundle, since other JRE > classes use types from the incomplete package ("uses" constraints in > OSGi terms). > > To work around this issue, we need to merge the existing classes in the > JRE package with the additional classes being exported by the exporting > bundle. The only way we can accomplish something like this in OSGi is to > do as Sahoo suggests and use boot delegation to find the existing JRE > classes, but have bundles still import the package so they can fall back > to the exporting bundle for the missing classes. > > This will work, since no JRE packages will depend on the missing > classes. We just need to make sure the exporting bundle is version > compatible with the JRE package. > > -> richard > >> >> thanks, >> -marina >> >> Sahoo wrote: >> >>> I think I know what's happening here. I am a bit surprised that it >>> didn't result in a "loader constraint violation," which is also a >>> LinkageError, but any way, I think I have an explanation for this >>> linkage error. >>> >>> /javap -classpath orb-iiop.jar -p -c >>> org.glassfish.enterprise.iiop.impl.GlassFishORBManager >>> /shows the following bytecodes: >>> * 495: invokestatic #114; //Method >>> com/sun/corba/ee/spi/osgi/ORBFactory.create:([Ljava/lang/String;Ljava/util/Properties;Z)Lcom/sun/corba/e >>> >>> e/spi/orb/ORB; >>> 498: putfield #2; //Field orb:Lorg/omg/CORBA/ORB; >>> * >>> Basically, it translates to something like this: >>> org.omg.CORBA.ORB something = >>> com.sun.corba.ee.spi.osgi.ORBFactory.create(properties); >>> >>> com.sun.corba.ee.spi.osgi.ORBFactory.create(Properties) returns >>> com.sun.corba.ee.spi.orb.ORB, which definitely extends >>> org.omg.CORBA.ORB for the code to compile. So, let's inspect the >>> hierarchy of this class: >>> >>> (*->* means extends and within bracket the jar that supplies the >>> class is mentioned as well. Each jar has a separate class loader) >>> >>> com.sun.corba.ee.spi.orb.ORB (/glassfish-corba-orb.jar/) >>> -> com.sun.corba.ee.org.omg.CORBA.ORB (/glassfish-corba-omgapi.jar/) >>> -> org.omg.CORBA_2_3.ORB (/JDK's rt.jar/) >>> -> org.omg.CORBA.ORB (/JDK's rt.jar/) >>> >>> Note a *duplication* of class in the runtime: >>> glassfish-corba-omgapi.jar exports org.omg.CORBA package and has >>> org.omg.CORBA.ORB.class in it. >>> JDK's rt.jar also has org.omg.CORBA.ORB.class. >>> >>> Since you *removed* org.omg.CORBA from system.packages list, >>> GlassFishORBManager, which is loaded from org-iiop.jar module, gets >>> org.omg.CORBA.ORB.class from glassfish-corba-omgapi.jar. As a result, >>> the simple assignment is looking like this: >>> >>> *org.omg.CORBA.ORB(glassfish-corba-omgapi.jar) = org.omg.CORBA.ORB >>> (JDK's rt.jar)* >>> >>> As you can see, they are two different types and hence the >>> VerificationError. >>> >>> There are several ways to *solve* it. >>> >>> 1. If you add a *bootdelegation* property for org.omg.CORBA package, >>> then everyone will see org.omg.CORBA.ORB(JDK's rt.jar) and that will >>> address the issue. Although this solution looks simple, it is not >>> preferred, as it is a violation of modularity principle. More over, >>> it leads to split packages which can lead to other issues at runtime >>> like access violation of package scoped objects. >>> >>> 2. If you remove all the org.omg CORBA related packages (including >>> org.omg.CORBA_2_3) from system packages list and ensure that they are >>> exported by glassfish-corba-omgapi bundle, then also every one will >>> see one version of classes and the problem will be solved. There is >>> an assumption here that no other JDK class other than the CORBA >>> implementation has direct reference to these packages. >>> >>> 3. If we can put glassfish-corba-omgapi.jar in one of the >>> java.endorsed.dirs and add all the new packages to system.packages >>> list, then also everyone see one consistent version of classes. Since >>> we can't assume we are using jre/lib/endorsed, this has the >>> disadvantage of requiring user to specify -Djava.endorsed.dirs in >>> command line, something which does not fly with "java -jar >>> glassfish.jar" style invocation. >>> >>> For now, I think we can start with option #2 and if we face any >>> issues, we can go to #1. >>> >>> Now let's see why the error was so cryptic in an OSGi environment. >>> After all, OSGi is supposed to give us more helpful errors. The >>> problem is our system packages are exported without any "uses" >>> clause. "uses" clause plays a vital role in package resolution and >>> correct specification of uses attribute might have given us a better >>> error stating the class space was not consistent. >>> >>> Hope that helps, >>> Thanks, >>> Sahoo >>> >>> Marina Vatkina wrote: >>> >>>> Team, >>>> >>>> Does anybody know what can cause this type of a LinkageError: >>>> >>>> Caused by: java.lang.VerifyError: (class: >>>> org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: >>>> initORB signature: (Ljava/util/Properties;)V) Bad type in >>>> putfield/putstatic >>>> at >>>> org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) >>>> >>>> at >>>> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) >>>> >>>> >>>> >>>> I see this error if I remove org.omg.CORBA package (only it, not its >>>> subpackages) from the >>>> glassfishv3/glassfish/osgi/felix/conf/config.properties (because >>>> it's available in the glassfish-corba-omgapi module) and then try to >>>> deploy an app with remote EJBs (i.e. force orb integration modules >>>> to be loaded). The same error happens on server restart if I first >>>> deploy the app, then modify the felix/conf/config.properties file. >>>> >>>> Googling for this error brings cases when 2 versions of the same >>>> class was present in 2 jars. But GlassFishORBManager is there in >>>> only one. Or a jdk 1.4 bug where you downcast the result to one of >>>> the interfaces (String to Clonable), which a) had been fixed back >>>> then and b) doesn't seem to be the case here as well :(. >>>> >>>> It doesn't make a difference whether I start GF via 'java -jar' or >>>> asadmin. >>>> >>>> Any ideas are greatly appreciated. >>>> >>>> thank you, >>>> -marina >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Sahoo
::
Rate this Message:
Marina Vatkina wrote:
> Richard S. Hall wrote: >> >> >> On 5/27/09 4:59 PM, Marina Vatkina wrote: >> >>> Ken, >>> >>> Is it possible to remove duplicate classes from the >>> glassfish-corba-xxx modules? >> >> >> The duplicate classes are not really the issue. The issue is that the >> built-in JRE package is incomplete, so we somehow need to add the >> missing classes to the package. > > If we really need to. Do we have the list of must-haves add-ons? > > For the org.omg.CORBA package, I know about TSIdentification that Ken > Cavanaugh said is possible to be moved to jts module, and the ORB > class that exists in 2 locations, JRE and glassfish-corba-omgapi.jar. > May be there are more case that I don't know about. If there are, and > there is nothing we can do to fix them, yes, we need to work around > the problem. Otherwise we might be able to fix it the right way (i.e. > remove duplicates and split packages). > > If we do fall back into the bootdelegation solution, unless it's too > time consuming, it would be nice to have the list of those classes > that we can't fix otherwise, won't it? > looks like. 1. Add org.omg.CORBA and org.omg.CORBA.* to bootdelegation list of packages. 2. Stop system bundle from exporting them. Either we can completely remove them or add a mandatory attribute. See how javax.transaction is handled in felix/conf.properties. 3. Package all the additional org.omg.CORBA classes in an osgi bundle and export them. The bundle *can* continue to contain all the org.omg.CORBA classes that exist in JRE. The duplication won't cause any problem because of bootdelegation. How we determine what are the extra classes? That's up to us. We can grow that list as time progresses. Sahoo > thanks, > -marina > > Unfortunately, we cannot just completely >> override the JRE package by placing it in a bundle, since other JRE >> classes use types from the incomplete package ("uses" constraints in >> OSGi terms). >> >> To work around this issue, we need to merge the existing classes in >> the JRE package with the additional classes being exported by the >> exporting bundle. The only way we can accomplish something like this >> in OSGi is to do as Sahoo suggests and use boot delegation to find >> the existing JRE classes, but have bundles still import the package >> so they can fall back to the exporting bundle for the missing classes. >> >> This will work, since no JRE packages will depend on the missing >> classes. We just need to make sure the exporting bundle is version >> compatible with the JRE package. >> >> -> richard >> >>> >>> thanks, >>> -marina >>> >>> Sahoo wrote: >>> >>>> I think I know what's happening here. I am a bit surprised that it >>>> didn't result in a "loader constraint violation," which is also a >>>> LinkageError, but any way, I think I have an explanation for this >>>> linkage error. >>>> >>>> /javap -classpath orb-iiop.jar -p -c >>>> org.glassfish.enterprise.iiop.impl.GlassFishORBManager >>>> /shows the following bytecodes: >>>> * 495: invokestatic #114; //Method >>>> com/sun/corba/ee/spi/osgi/ORBFactory.create:([Ljava/lang/String;Ljava/util/Properties;Z)Lcom/sun/corba/e >>>> >>>> e/spi/orb/ORB; >>>> 498: putfield #2; //Field orb:Lorg/omg/CORBA/ORB; >>>> * >>>> Basically, it translates to something like this: >>>> org.omg.CORBA.ORB something = >>>> com.sun.corba.ee.spi.osgi.ORBFactory.create(properties); >>>> >>>> com.sun.corba.ee.spi.osgi.ORBFactory.create(Properties) returns >>>> com.sun.corba.ee.spi.orb.ORB, which definitely extends >>>> org.omg.CORBA.ORB for the code to compile. So, let's inspect the >>>> hierarchy of this class: >>>> >>>> (*->* means extends and within bracket the jar that supplies the >>>> class is mentioned as well. Each jar has a separate class loader) >>>> >>>> com.sun.corba.ee.spi.orb.ORB (/glassfish-corba-orb.jar/) >>>> -> com.sun.corba.ee.org.omg.CORBA.ORB >>>> (/glassfish-corba-omgapi.jar/) >>>> -> org.omg.CORBA_2_3.ORB (/JDK's rt.jar/) >>>> -> org.omg.CORBA.ORB (/JDK's rt.jar/) >>>> >>>> Note a *duplication* of class in the runtime: >>>> glassfish-corba-omgapi.jar exports org.omg.CORBA package and has >>>> org.omg.CORBA.ORB.class in it. >>>> JDK's rt.jar also has org.omg.CORBA.ORB.class. >>>> >>>> Since you *removed* org.omg.CORBA from system.packages list, >>>> GlassFishORBManager, which is loaded from org-iiop.jar module, gets >>>> org.omg.CORBA.ORB.class from glassfish-corba-omgapi.jar. As a >>>> result, the simple assignment is looking like this: >>>> >>>> *org.omg.CORBA.ORB(glassfish-corba-omgapi.jar) = org.omg.CORBA.ORB >>>> (JDK's rt.jar)* >>>> >>>> As you can see, they are two different types and hence the >>>> VerificationError. >>>> >>>> There are several ways to *solve* it. >>>> >>>> 1. If you add a *bootdelegation* property for org.omg.CORBA >>>> package, then everyone will see org.omg.CORBA.ORB(JDK's rt.jar) and >>>> that will address the issue. Although this solution looks simple, >>>> it is not preferred, as it is a violation of modularity principle. >>>> More over, it leads to split packages which can lead to other >>>> issues at runtime like access violation of package scoped objects. >>>> >>>> 2. If you remove all the org.omg CORBA related packages (including >>>> org.omg.CORBA_2_3) from system packages list and ensure that they >>>> are exported by glassfish-corba-omgapi bundle, then also every one >>>> will see one version of classes and the problem will be solved. >>>> There is an assumption here that no other JDK class other than the >>>> CORBA implementation has direct reference to these packages. >>>> >>>> 3. If we can put glassfish-corba-omgapi.jar in one of the >>>> java.endorsed.dirs and add all the new packages to system.packages >>>> list, then also everyone see one consistent version of classes. >>>> Since we can't assume we are using jre/lib/endorsed, this has the >>>> disadvantage of requiring user to specify -Djava.endorsed.dirs in >>>> command line, something which does not fly with "java -jar >>>> glassfish.jar" style invocation. >>>> >>>> For now, I think we can start with option #2 and if we face any >>>> issues, we can go to #1. >>>> >>>> Now let's see why the error was so cryptic in an OSGi environment. >>>> After all, OSGi is supposed to give us more helpful errors. The >>>> problem is our system packages are exported without any "uses" >>>> clause. "uses" clause plays a vital role in package resolution and >>>> correct specification of uses attribute might have given us a >>>> better error stating the class space was not consistent. >>>> >>>> Hope that helps, >>>> Thanks, >>>> Sahoo >>>> >>>> Marina Vatkina wrote: >>>> >>>>> Team, >>>>> >>>>> Does anybody know what can cause this type of a LinkageError: >>>>> >>>>> Caused by: java.lang.VerifyError: (class: >>>>> org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method: >>>>> initORB signature: (Ljava/util/Properties;)V) Bad type in >>>>> putfield/putstatic >>>>> at >>>>> org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29) >>>>> >>>>> at >>>>> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170) >>>>> >>>>> >>>>> >>>>> I see this error if I remove org.omg.CORBA package (only it, not >>>>> its subpackages) from the >>>>> glassfishv3/glassfish/osgi/felix/conf/config.properties (because >>>>> it's available in the glassfish-corba-omgapi module) and then try >>>>> to deploy an app with remote EJBs (i.e. force orb integration >>>>> modules to be loaded). The same error happens on server restart if >>>>> I first deploy the app, then modify the >>>>> felix/conf/config.properties file. >>>>> >>>>> Googling for this error brings cases when 2 versions of the same >>>>> class was present in 2 jars. But GlassFishORBManager is there in >>>>> only one. Or a jdk 1.4 bug where you downcast the result to one of >>>>> the interfaces (String to Clonable), which a) had been fixed back >>>>> then and b) doesn't seem to be the case here as well :(. >>>>> >>>>> It doesn't make a difference whether I start GF via 'java -jar' or >>>>> asadmin. >>>>> >>>>> Any ideas are greatly appreciated. >>>>> >>>>> thank you, >>>>> -marina >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Sahoo
::
Rate this Message:
Sahoo wrote:
> Marina Vatkina wrote: >> Richard S. Hall wrote: >>> >>> >>> On 5/27/09 4:59 PM, Marina Vatkina wrote: >>> >>>> Ken, >>>> >>>> Is it possible to remove duplicate classes from the >>>> glassfish-corba-xxx modules? >>> >>> >>> The duplicate classes are not really the issue. The issue is that >>> the built-in JRE package is incomplete, so we somehow need to add >>> the missing classes to the package. >> >> If we really need to. Do we have the list of must-haves add-ons? >> >> For the org.omg.CORBA package, I know about TSIdentification that Ken >> Cavanaugh said is possible to be moved to jts module, and the ORB >> class that exists in 2 locations, JRE and glassfish-corba-omgapi.jar. >> May be there are more case that I don't know about. If there are, and >> there is nothing we can do to fix them, yes, we need to work around >> the problem. Otherwise we might be able to fix it the right way (i.e. >> remove duplicates and split packages). >> >> If we do fall back into the bootdelegation solution, unless it's too >> time consuming, it would be nice to have the list of those classes >> that we can't fix otherwise, won't it? >> > The solution is *not* time consuming. Here is how the final solution > looks like. > > 1. Add org.omg.CORBA and org.omg.CORBA.* to bootdelegation list of > packages. > 2. Stop system bundle from exporting them. Either we can completely > remove them or add a mandatory attribute. See how javax.transaction is > handled in felix/conf.properties. > 3. Package all the additional org.omg.CORBA classes in an osgi bundle > and export them. The bundle *can* continue to contain all the > org.omg.CORBA classes that exist in JRE. The duplication won't cause > any problem because of bootdelegation. How we determine what are the > extra classes? That's up to us. We can grow that list as time progresses. > > Sahoo for why duplicate classes is not an issue with this approach. Thanks, Sahoo --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Sahoo
::
Rate this Message:
Richard S. Hall wrote:
> On 5/27/09 1:29 PM, Sahoo wrote: >> Richard S. Hall wrote: >>> On 5/27/09 12:31 PM, Sahoo wrote: >>>> This is good information. This can be used to arrive at a proper >>>> solution. I am inclined to say solution #2 (see my previous email) >>>> will require us to package a lot of classes in OSGi bundles, >>>> because there will be other JDK packages which depends on this set >>>> of packages and all of them have to be repackaged. It may not be >>>> legal to do so. Even if it is legal, it may just be too heavyweight >>>> a solution. So, #1 may be only viable solution. Do you agree? >>> >>> I think the answer depends, but ultimately you may be correct. >>> >>> However, if we can adopt boot delegation as a solution, then it >>> seems to be equivalent of saying that it is not necessary for any >>> other bundle to export what we are boot delegating, since everyone >>> will use the JRE package. If that is true, then we should be able to >>> remove the duplicate package from the exporting bundle and just >>> export it from the system bundle from which every bundle will import >>> it, no? >>> >> Not really unless I am misunderstanding you. It's an ugly >> split-package issue. As I mentioned somewhere in that email, JDK >> contains partial list of classes for some of those packages. So, we >> need to have another bundle export those packages, so that when >> bootdelegation fails to locate one of those extra classes, it can be >> found traversing Import-Package wiring. >> >> We have the same issue with javax.transaction. javas.sql, which is >> coming from rt.jar, depends on javax.transaction, but rt.jar has only >> a few of the javax.transaction classes. So, we bootdelegate >> javax.transaction in addition to having our own javax.transaction >> bundle which has all the classes. > > Ok, so we are using boot delegation to create the union of the partial > JRE package with the bundle exported package, essentially. Yes, I > don't see another way to deal with that. The proper approach would be > to replace the JRE packages completely, since they appear to be faulty > (since they are incomplete); however, I agree that this would likely > entail re-packaging much more than the offending package due to "uses" > constraints. > Thanks for confirming. We will proceed with this approach. Sahoo --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: LinkageError caused by java.lang.VerifyError ... Bad type in putfield/putstatic ?
by Marina Vatkina
::
Rate this Message:
Sahoo wrote:
> Sahoo wrote: > >> Marina Vatkina wrote: >> >>> Richard S. Hall wrote: >>> >>>> >>>> >>>> On 5/27/09 4:59 PM, Marina Vatkina wrote: >>>> >>>>> Ken, >>>>> >>>>> Is it possible to remove duplicate classes from the >>>>> glassfish-corba-xxx modules? >>>> >>>> >>>> >>>> The duplicate classes are not really the issue. The issue is that >>>> the built-in JRE package is incomplete, so we somehow need to add >>>> the missing classes to the package. >>> >>> >>> If we really need to. Do we have the list of must-haves add-ons? >>> >>> For the org.omg.CORBA package, I know about TSIdentification that Ken >>> Cavanaugh said is possible to be moved to jts module, and the ORB >>> class that exists in 2 locations, JRE and glassfish-corba-omgapi.jar. >>> May be there are more case that I don't know about. If there are, and >>> there is nothing we can do to fix them, yes, we need to work around >>> the problem. Otherwise we might be able to fix it the right way (i.e. >>> remove duplicates and split packages). >>> >>> If we do fall back into the bootdelegation solution, unless it's too >>> time consuming, it would be nice to have the list of those classes >>> that we can't fix otherwise, won't it? >>> >> The solution is *not* time consuming. Here is how the final solution >> looks like. I meant the opposite could be time consuming (i.e. identify and fix - if possible - all split packages). >> >> 1. Add org.omg.CORBA and org.omg.CORBA.* to bootdelegation list of >> packages. >> 2. Stop system bundle from exporting them.Either we can completely >> remove them or add a mandatory attribute. See how javax.transaction is >> handled in felix/conf.properties. If I remove all org.omg.CORBA.*, Felix can't start saying unresolved constraint in org.omg.CORBA.portable. For now it looks like it's enough to only add org.omg.CORBA to bootdelegation and remove it from the list of system packages. I do see only org.omg.CORBA itself in the glassfish-corba-xxx jars. Do you see a problem with not touching the subpackages? thanks, -marina >> 3. Package all the additional org.omg.CORBA classes in an osgi bundle >> and export them. The bundle *can* continue to contain all the >> org.omg.CORBA classes that exist in JRE. The duplication won't cause >> any problem because of bootdelegation. How we determine what are the >> extra classes? That's up to us. We can grow that list as time progresses. >> >> Sahoo > > I forgot to mention. Look at the explanation in one of Richard's email > for why duplicate classes is not an issue with this approach. > > Thanks, > Sahoo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
