[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

Andrew Lee Rubinger andrew.rubinger at redhat.com
Wed Apr 1 04:04:23 EDT 2009


Carlo de Wolf wrote:
> Where to begin?
> This question is actually the one we are going to debate. Where does 
> Application Server begin and where does it end?
> But there is more to it: I want to be able to unit test EJB3 before 
> bringing it to AS. (I think it should become a requirement of any 
> component to be able to run/test standalone before coming to AS/EAP, but 
> that's another discussion.)
> 
> Let's start with the simple one: JBoss Bootstrap:
> As of AS 5.1 the application server no longer performs the bootstrapping 
> of profile service. Instead AS defines a bootstrap descriptor and 
> delegates bootstrapping it to JBoss Bootstrap.

There are a few issues in place with the existing Bootstrap mechanism. 
It's very fragile as to what's located on the application CP (and thus 
picked up by the extension ClassLoader).  Too much or too little on 
there and we get either CCE or NCDFE.

There are 2 sticky bits in particular:

1) ServerLoader using NoAnnotationCL (URLCL) to pick up stuff in 
$JBOSS_HOME/lib before loading the server implementation class
2) The Server is always started using the TCCL of the CL which loaded 
the server implementation class.  If this CL doesn't have 
$JBOSS_HOME/common/lib etc on it, CNFE.

This is all working harmoniously in AS presently due to the clever 
run.jar on the application CP, which is selective with the classes it 
contains (ie. jboss-bootstrap SPIs, but not the impl classes).  Once we 
start to use Boostrap in other environments it fails real tests for 
robustness.

I believe dropping ClassLoading from jboss-bootstrap would help to put 
CL definition out of scope for this component.  For the guys who've been 
here before, what are some repercussions I haven't considered?

The goal is to make jboss-bootstrap usable from a greater variety of 
boot scenarios, not just ./run.sh.

> Now the most complex one in terms of definition: JBoss Embedded.
> It's *not* Embedded JBoss ( http://www.jboss.org/community/docs/DOC-9690 
> ), which was a preview of AS 5 capabilities (previously known as EJB 3.0 
> Embeddable).
> It is *not* EJB 3 Embedded, which is a preview of EJB 3.1 Embeddable 
> specification.
> 
> The scope of JBoss Embedded is currently defined as:
> * Software component which, in tandem with an arbitrary AS 
> distribution,  launches JBossAS in preexisting JVM.
> * Conforms to all existing AS TestSuites and TCK (fully-compatible) when 
> in a JavaSE environment. Whether AS is launched from run.sh or Embedded 
> should be transparent to applications.
> 
> Which leaves the following bits out of scope:
> * Bundling alongside JBossAS (in the AS release cycle)
> * Virtual JAR deployment.  This may later be handled by user extensions 
> into VFS, such that user code may assemble an EAR or JAR view 
> programatically, and pass that along to the AS deployment mechanism.
> * Compatibility from launch inside arbitrary runtimes like Tomcat, 
> WebSphere.

I'll expand on this working definition a bit.

* Provide an end-user API for configuration and interacting with the 
server (lifecycle, Kernel, Deployment, MBean Server, etc).

Regardless of how the tech works behind the scenes (some combination of 
Reloaded and Bootstrap), I like Embedded as the facade atop everything 
which gives users a good configuration/control mechanism.

Currently I've got this is doing a simple boot of AS in $JBOSS_HOME:

http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk/testsuite/src/test/java/org/jboss/embedded/test/server/ServerUnitTestCase.java
https://jira.jboss.org/jira/browse/EMB-22

S,
ALR

-- 
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com



More information about the jboss-development mailing list