"ALRubinger" wrote:

* Removal of NoAnnotationCL - a URLCL which is commented to be used in RMI. Is this still the case?

This should no longer be useful as we should be using remoting for transport everywhere now.

"ALRubinger" wrote:

* AbstractServerImpl.start() to use the TCCL. Currently it's using 2 different CLs (one for starting the ServerImpl, one for the bootstraps).

Don't know about that.

 

"scott.stark@jboss.org" wrote:

"ALRubinger" wrote:

* Removal of NoAnnotationCL - a URLCL which is commented to be used in RMI. Is this still the case?

This should no longer be useful as we should be using remoting for transport everywhere now.

Other people still use RMI and so do we if we want to talk to old jboss servers.
We don't want all the junk going across the wire that RMI adds if you use
a plain URL classloader.

 

"ALRubinger" wrote:
https://jira.jboss.org/jira/browse/JBBOOT-24

As it stands, Bootstrap is sensitive to arbitrary JARs on the application CP (and picked up by the extension ClassLoader). This becomes especially apparent when starting up from an Embedded environment, where we may have a full dependency set on the test CP.

AS currently sidesteps this problem by careful inclusion of classes in the run.jar.

What I'd like to do is remove setting of the TCCL from jboss-bootstrap entirely, leaving this task up to the client (launcher). Some local tests yield much better results and allow the bootstrap to become adaptable to a wider range of runtime environments.

The basic idea is to have a pluggable bootstrap. The bootstrap.start() should run
under its own classloader as TCL not the classpath otherwise all sort of side effects
break (e.g. loading property editors, and other dynamic classloading, etc.).

In JBoss the bootstrap is two stage (actually it is multiple).

1) To load the bootstrap implementation itself (the mc + profile service)
2) To load the bootstrap xmls

As long as the called code doesn't have to worry about setting the TCL itself
(error prone and it is not likely to know what the correct CL is)
I don't have a problem.

 

"adrian@jboss.org" wrote:
The basic idea is to have a pluggable bootstrap. The bootstrap.start() should run
under its own classloader as TCL not the classpath otherwise all sort of side effects
break (e.g. loading property editors, and other dynamic classloading, etc.).

I still don't see how this can happen?
The app classloader contains virtually nothing.

"adrian@jboss.org" wrote:
In JBoss the bootstrap is two stage (actually it is multiple).

1) To load the bootstrap implementation itself (the mc + profile service)

Profile Service isn't in scope yet. We're at rock bottom, stage #1, a bootstrapping framework with which Reloaded can bootstrap Profile Service itself.

"adrian@jboss.org" wrote:

2) To load the bootstrap xmls

As long as the called code doesn't have to worry about setting the TCL itself
(error prone and it is not likely to know what the correct CL is)
I don't have a problem.

I think I'm getting it: Bootstrap should execute the following 'psuedo' descriptor:

<deployment>
 <classloader>preboot-cl</classloader>
 <bean class="org.jboss.bootstrap.MCServerImpl"/>
 <bean class="org.jboss.bootstrap.BootstrapDeployer"/>
 <classloader name="preboot-cl">
 bits and pieces specified by the launcher
 </classloader>
</deployment>