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
>