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_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>