[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Recursive JDKCheckerFactory usage?

[adrian@jboss.org]

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).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166606#4166606

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166606