[jboss-dev] AS ClassLoading in Embedded Environments

[Bill Burke]

I think what I did for old EMbedded JBoss was to have everything in 
system classpath.

This won't work though I think because some components will require 
isolation.

Why not just require the user to do:

Thread.currentThread().setContextClassLoader(EmbeddedClassloader);

???

If a maven plugin is ever created, the maven plugin could do this. 
Maybe take an existing application (like from the O'Reilly EJB3 book or 
something) and decide how you as a user would like it to be and go from 
there?

Andrew Lee Rubinger wrote:
> 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
> 

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com