9:01 p.m.
Yes, this is exactly what we do presently.
Either:
1) Everything on --classpath[1]
2) Require the user to set TCCL to a special ClassLoader[2]
I was hoping that 2) could still be a phased CL model where the special
ClassLoader (JBossHomeClassLoader) is still a more minimal set to start
MC and let jboss-cl take over at the appropriate time.
Instead I think due to class references leaking we need to make
JBossHomeClassLoader a more flat CL model equipped with everything in
common/lib, lib, and server/name/lib. This should still give us a
smaller runtime launch dependency.
Agree with your points on the Maven plugin and O'Reilly EJB3 examples.
In fact, it's my work w/ the book examples that keep showing me places
we can/must improve usability in this area. I want even setting the
TCCL to be abstracted out, and we've got a couple ways to do this:
1) Maven Plugin does it
2) Arquillian does it
3) Hardcode a bootstrap lifecycle callback to do it. :)
4) User manually does it
My concern really is with this flat, everything-up-at-a-parent-CL
approach. Failing separation in the subprojects JARs though, I don't
think it can be avoided now.
S,
ALR
[1] http://community.jboss.org/docs/DOC-14441
[2] http://community.jboss.org/docs/DOC-14447
On 01/29/2010 09:42 PM, Bill Burke wrote:
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
>
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger