[jboss-dev] AS ClassLoading in Embedded Environments

[Adrian Brock]

I don't get it?

You've created this dependency by making your embedded server impl
depend on deployers-vfs-spi.

https://svn.jboss.org/repos/jbossas/projects/embedded/trunk/core/src/main/java/org/jboss/embedded/core/server/JBossASEmbeddedServerImpl.java

import org.jboss.deployers.vfs.spi.client.VFSDeploymentFactory;

If you're not doing what jboss-as does, i.e. use a peer classloading
model for those classes, then all the stuff you've compiled over 
(imported) needs to be in the same classloader (or a parent
classloader). 

Its the classpath in your case, so run
mvn dependency:tree 
in your embedded project to work out the classpath.

Alternatively, don't compile over those classes and use an
interface/delegate (or reflection with dynamic classloading) for 
that stuff to keep the classes in the classpath to a minimum.

I'm not sure what you gain by minimising the classpath
for this stuff, other than making it configurable in some xml?
That's why we do it that way in jboss-as. 

P.S. This is very ugly, you're depending too much on impl
details of the AS distribution structure.
https://svn.jboss.org/repos/jbossas/projects/embedded/trunk/api/src/main/java/org/jboss/embedded/api/server/JBossHomeClassLoader.java
e.g. version control/maintenance problems when the appserver
changes but you don't either because you're not on the same 
release cycle or the AS developer (especially the ones that
can't keep their fingers off the refactoring button :-)
simply doesn't know this dependency exists.

On Fri, 2010-01-29 at 14:22 -0500, 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
> 

-- 
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx