Can 4.2.1 work on GlassFish/OSGi? New way of setting class loader breaks modules

[Arjan Tijms]

In 4.2.1 the class loader to generate stubs has been changed from the context class loader to that of the one for which the stub is generated:

public Class<?> create( ProtectionDomain pd, ClassLoader cl,
        boolean debug, PrintStream ps ) {

        Pair<String,String> nm = splitClassName( className ) ;

        _clear() ;
        _setClassLoader( cl ) ;

vs

public Class<?> create( Class<?> anchorClass,
         boolean debug, PrintStream ps ) {

          Pair<String,String> nm = splitClassName( className ) ;

          _clear() ;
         _setClassLoader( anchorClass.getClassLoader() ) ;

See 471b980#diff-9cebdcf343a6c675195053fd3449dbcaR197

The effect is that the PFL code (org.glassfish.pfl.dynamic.codegen.spi.Type) called later may not have access to a lot of types needed. For instance javax.rmi.CORBA.Stub if the bundle for which the proxy/stub happens to be generated doesn't have this imported. This results in errors like e.g.:

Class 'javax.rmi.CORBA.Stub' was not found because bundle 
    org.glassfish.main.common.glassfish-naming [243] 
does not import 
    'javax.rmi.CORBA' 
even though bundle 
     org.glassfish.corba.glassfish-corba-omgapi [45] {
         bundle-symbolic-name=org.glassfish.corba.glassfish-corba-omgapi, 
         bundle-version=4.2.1, 
         version=1.0.0, 
         osgi.wiring.package=javax.rmi.CORBA} 
does export it. 
           
Additionally, the class is also available from the system class loader. 
           
There are two fixes: 
 
1) Add an import for 'javax.rmi.CORBA' to bundle org.glassfish.main.common.glassfish-naming [243]; imports are necessary for each class directly touched by bundle code or indirectly touched, such as super classes if their methods are used. 
                       
2) Add package 'javax.rmi.CORBA' to the 'org.osgi.framework.bootdelegation' property; a library or VM bug can cause classes to be loaded by the wrong class loader. 
                               
The first approach is preferable for preserving modularity. ***

In 4.2.0 the context class loader would be used, which would have the following chain:

 BundleImpl.loadClass(String) line: 958 --> GlassFish-Application-Common-Module [109]
 OSGiModuleImpl$4$1.run() line: 408	
 OSGiModuleImpl$4$1.run() line: 405	
 AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method]	
 OSGiModuleImpl$4.loadClass(String, boolean) line: 405	
 OSGiModuleImpl$4(ClassLoader).loadClass(String) line: 357	
 APIClassLoaderServiceImpl$APIClassLoader.loadClass(String, boolean) line: 214	
 URLClassLoader(ClassLoader).loadClass(String, boolean) line: 411	
 DelegatingClassLoader(ClassLoader).loadClass(String, boolean) line: 411	
 ASURLClassLoader(ClassLoader).loadClass(String, boolean) line: 411

GlassFish-Application-Common-Module is capable of loading 'javax.rmi.CORBA', but also to load classes that come from other bundles, such as com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase

Note that the class loader in PFL is used e.g. here:

public Class<?> getTypeClass() {
    if (typeClass == null) {
        try {
            typeClass = Class.forName( name, true, CurrentClassLoader.get() ) ;
        } catch (ClassNotFoundException cnfe) {
            IllegalArgumentException exc = 
                new IllegalArgumentException( 
                    "Cannot load class for type " + name ) ;
                    exc.initCause( cnfe ) ;
                    throw exc ;
        }
        // [...]
}

cc @hs536 @m0mus

[Arjan Tijms]

ping @bshannon @m0mus

[Steve Millidge]

Was this fixed by #58 ?

[Arjan Tijms]

@smillidge

Was this fixed by #58 ?

At a glance, doesn't seem like it. This is mostly about using the anchor (stub) class loader, as per the fragment anchorClass.getClassLoader().

Pinging @russgold and @m0mus

[Steve Millidge]

Can you do a PR if you know the fix? I'm a committer as well on ORB.

[Bill Shannon]

I don't know the code and can't do a PR but if you apply the fix and it works for you
I'll approve the PR.

[Arjan Tijms]

Looking at the code for only a bit the quick "solution" I see is reverting it back to how it was before, but that will likely cause JDK 11 issues, as the change was done by @russgold to support JDK 11.

[Hiroki Sawamura]

I have confirmed that GlassFish devtests pass with the orb module containing this commit on JDK 11. Is it possible to prepare an application that may cause the problem?

[Arjan Tijms]

@hs536

If I remember correctly it’s just starting up GlassFish.

[Arjan Tijms]

@hs536 After retesting, something had changed seemingly causing me not able to reproduce this anymore. I'll update GF with 4.2.1 then and close this issue. It's quite hard to see what went wrong earlier under which circumstances, and what exactly causes it to work now.