[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

[Carlo de Wolf]

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.
Effectively this allows anybody to create an arbitrary bootstrap, for 
example:
   <?xml version="1.0" encoding="UTF-8"?>
   <bootstrap xmlns="urn:jboss:bootstrap:1.0">
      <url>bootstrap/naming.xml</url>
      <url>bootstrap/jmx-jdk.xml</url>
      <url>bootstrap/jbossts.xml</url>
   </bootstrap>
Voilà instant JTA compliant transaction server.

The best part is, that it's using the same components as the real AS, so 
it should be close to 100% compatible.


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.


What I've really left out so far is the goal we're trying to achieve: 
unit testing. I would say both unit testing of user applications & unit 
testing of services.
So there I was sitting behind my screen setting up a new component: 
ejb3-jndibinder. Recreating another bootstrap...
Hmm, that's not how I want to do it with every component.

In comes JBoss Reloaded, because I actually want to have a single 
component dependency which gives me the proper environment to run my 
unit test in. So I only should need: jpa-profile (whichs depends on 
jta-profile, which depends on naming-profile (I'll leave jca-profile out 
of scope for a moment)).
For this to work Reloaded defines a vdf-bootstrap / 
profile-service-bootstrap and it should also provide a facility to plug 
profiles.

http://www.jboss.org/community/docs/DOC-13453

To plug stuff into the bootstrap descriptor itself it uses 
repoclassloader ( https://jira.jboss.org/jira/browse/RELOADED-2 ).
And to make it more extensible allow for compound classloaders ( 
https://jira.jboss.org/jira/browse/RELOADED-4 ).


Now the bits where it gets real fun: JBoss Embedded & JBoss Reloaded can 
both boot AS 5.0.1, AS 5.1 and AS 6. :-)
JBoss Embedded does this by virtue of the fact that all these three AS 
versions adhere to the same Bootstrap contract, so it can point 
Bootstrap to the proper descriptors.
JBoss Reloaded does this by virtue of defining a proper bootstrap and 
booting up the right Profile Service (from the repository) and pointing 
that Profile Service to the AS ( 
https://jira.jboss.org/jira/browse/RELOADED-3 as a showcase ).

Which brings us to the question of where should Application Server 
begin? Where does it get it's Main from?
The bootstrap descriptors themselves are going to be moved to 
jboss-reloaded-vdf-bootstrap. Note that this still requires components 
to be broken out of AS.
By answering these question we can lock down the scope of Embedded & 
Reloaded.

Carlo