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 >

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.

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.

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

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 >