Recursive JDKCheckerFactory usage?

[starksm64]

I'm seeing this NPE an app client test usage I'm trying to create a testcase for:

153771 ERROR [AbstractKernelController] Error installing to Instantiated: name=ClientContainer state=Described
java.lang.ExceptionInInitializerError
 at org.jboss.classloader.spi.ClassLoaderPolicy.isJDKRequest(ClassLoaderPolicy.java:220)
 at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:228)
 at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1056)
 at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:728)
 at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 at java.beans.Introspector.instantiate(Introspector.java:1453)
 at java.beans.PropertyEditorManager.findEditor(PropertyEditorManager.java:91)
 at org.jboss.reflect.plugins.ValueConvertor.convertValue(ValueConvertor.java:136)
 at org.jboss.reflect.plugins.ClassInfoImpl.convertValue(ClassInfoImpl.java:491)
 at org.jboss.reflect.spi.DelegateClassInfo.convertValue(DelegateClassInfo.java:236)
 at org.jboss.beans.metadata.plugins.StringValueMetaData.getValue(StringValueMetaData.java:125)
 at org.jboss.kernel.plugins.config.Configurator.getParameters(Configurator.java:593)
 at org.jboss.kernel.plugins.config.Configurator.getConstructorJoinPoint(Configurator.java:188)
 at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getConstructorJoinPoint(AbstractKernelConfigurator.java:132)
 at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:57)
 at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:1)
 at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
 at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
 at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1394)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:786)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:914)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:836)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:626)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:443)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:331)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:309)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
 at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
 at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88)
 at org.jboss.test.classloading.vfs.client.support.launcher.ClientLauncher.deploy(ClientLauncher.java:258)
 at org.jboss.test.classloading.vfs.client.support.launcher.ClientLauncher.launch(ClientLauncher.java:404)
 at org.jboss.test.classloading.vfs.client.test.ClientClassPathUnitTestCase.testClientMainClassPath(ClientClassPathUnitTestCase.java:119)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ...
Caused by: java.lang.NullPointerException
 at org.jboss.classloader.spi.ClassLoaderPolicy.isJDKRequest(ClassLoaderPolicy.java:221)
 at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:228)
 at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1056)
 at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:728)
 at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 at org.jboss.classloader.spi.jdk.JDKCheckerFactory$1.run(JDKCheckerFactory.java:56)
 at org.jboss.classloader.spi.jdk.JDKCheckerFactory$1.run(JDKCheckerFactory.java:1)
 at java.security.AccessController.doPrivileged(Native Method)
 at org.jboss.classloader.spi.jdk.JDKCheckerFactory.<clinit>(JDKCheckerFactory.java:43)
 ... 55 more

I'll check in the test even though its currently failing. I'm having trouble restricting the load of the app client main through the vfs class loader of the mc deployment since its visible to the system class loader.

[starksm64]

org.jboss.test.classloading.vfs.client.test.ClientClassPathUnitTestCase is the testcase I'm working on.

[adrian.brock]

It's a bug.

It's trying to see whether this is the JDK trying to load a system class
e.g. sun.*
but not using the system classloader. i.e. it expects to be able to load
them from any classloader.

But in this case the JDKChecker hasn't been initialized so it tries
to load the implementation through the TCL which in this case is a BaseClassLoader

at org.jboss.classloader.spi.ClassLoaderPolicy.isJDKRequest(ClassLoaderPolicy.java:221)
 at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:228)
...
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 at org.jboss.classloader.spi.jdk.JDKCheckerFactory$1.run(JDKCheckerFactory.java:56)
 at org.jboss.classloader.spi.jdk.JDKCheckerFactory$1.run(JDKCheckerFactory.java:1)
 at java.security.AccessController.doPrivileged(Native Method)
 at org.jboss.classloader.spi.jdk.JDKCheckerFactory.<clinit>(JDKCheckerFactory.java:43)

So it ends up calling itself before it is properly nitialized.

There's one of two possible fixes:

1) Ignore loading from the TCL when it is a BaseClassLoader in
JDKCheckerFactory

2) Use the "default" JDKChecker (AbstractJDKChecker)
if JDKCheckerFactory returns null,
i.e. it is part way through loading a custom checker from the current classloader

(2) Is a bit hacky, but it does allow custom JDKCheckers to be outside
$JBOSS_HOME/lib

You should be able to workaround the problem for now by doing
JDKChecker..getChecker()
before you setup the classloading (or at least before you setup the TCL).

[adrian.brock]

1) Ignore loading from the TCL when it is a BaseClassLoader in
JDKCheckerFactory

Actually, this is probably a bit naive since the BaseClassLoader could be wrapped,
e.g. EJB2.

[adrian.brock]

JIRA: https://jira.jboss.org/jira/browse/JBCL-21

I've got it as far as this:

2230 ERROR [ClientClassPathUnitTestCase] ClientLauncher.exception:
java.lang.ClassCastException: class org.jboss.test.classloading.vfs.client.support.launcher.ClientContainer{cl=BaseClassLoader@18bd7f1{Clien
tLauncherClassLoader:0.0.0$MODULE} codeSource=(vfsfile:/home/ejort/jboss-cl/classloading-vfs/target/tests-classes/ <no signer certificates>)
} is not an instanceof class org.jboss.test.classloading.vfs.client.support.launcher.ClientContainer{cl=sun.misc.Launcher$AppClassLoader@1a5
ab41 codeSource=(file:/home/ejort/jboss-cl/classloading-vfs/target/tests-classes/ <no signer certificates>)}
 at org.jboss.test.classloading.vfs.client.support.launcher.ClientLauncher.getBean(ClientLauncher.java:147)
 at org.jboss.test.classloading.vfs.client.support.launcher.ClientLauncher.launch(ClientLauncher.java:407)

So it is failing now because you're instantiating the ClientContainer using the
BaseClassLoader but the ClientLauncher bootstrap is referencing the
one from the classpath.

[adrian.brock]

I've changed the test to use reflection and now it passes.

[adrian.brock]

I did some other "fixes" to the test such as add a TestSuite static method
so the support structure (the test delegate) is properly initialized
and also added an "empty" file to lib.jar otherwise maven won't copy the directory.