[jboss-dev] AS ClassLoading in Embedded Environments

Andrew Lee Rubinger andrew.rubinger at redhat.com
Fri Jan 29 14:22:38 EST 2010


Open call for comments/suggestions.  I'm running low on ideas.

ClassLoading in AS has a few phases:

1) Launch (application classpath, run.jar, some minimal APIs only)
2) Bootstrap (A bunch of JARs in $JBOSS_HOME/lib, enough to start the 
Kernel and deploy the bootstraps)
3) Service Deployments (jboss-cl takes over, adding in support from 
$JBOSS_HOME/common as appropriate)

In an Embedded environment, the client is in the same JVM as the server. 
  The TCCL of the Main Thread needs to be able to:

* Establish a JNDI Context via "new InitialContext();"
* Deploy

For these, TCCL needs to have access to runtime internals provided via 
jbossall-client.jar.  If this is loaded by a parent CL of something it 
references, we get NCDFE.  For instance:

java.lang.NoClassDefFoundError: 
org/jboss/deployers/vfs/spi/client/VFSDeploymentFactory
	at 
org.jboss.embedded.core.server.JBossASEmbeddedServerImpl.deploy(JBossASEmbeddedServerImpl.java:256)

Here the AS deployment mechanism is loaded in a ClassLoader higher in 
the hierarchy than VFS Deployers SPI.  I could move where we load VFS 
Deployers SPI higher up, which would then leak out something else, and 
on and on.

I currently cannot concoct an environment where:

* User has a minimal application ClassPath
* Other ClassLoading is transparent
* Everything works

Some attempt to use an isolated ClassLoader result in ClassCastException 
when equal FQNs end up w/ separate defining ClassLoaders.

I believe I'm trying in vain to hack around the underlying problem where 
the AS module system is not separated out to support this kind of use. 
We have ClassLoading requirements not being met:

* JARs safe for client use at all CL levels (ie. no references to 
outside dependencies which would also need to be loaded by the same CL)
* JARs for compilation only, and runtime will be provided by the 
container (ie. Maven scope "provided")
* JARs used by AS internals *only*.

For now I think the only way forward is to either put:

1) Every single one of AS's dependencies on the application ClassPath
   * http://community.jboss.org/docs/DOC-14441
2) Use a JBossHomeClassLoader which refers out to every AS runtime 
dependency in $JBOSS_HOME/lib, $JBOSS_HOME/common/lib, and the server libs.

S,
ALR

-- 
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger



More information about the jboss-development mailing list