[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

[Carlo de Wolf]

I think we can say that the entire scope of JBoss Embedded is too large 
to handle right now. The current prototype goes a long way, but doesn't 
cover some pieces which are wanted:
- self-containment
- distribution

So we define a new component: JBoss Launcher, which has as a goal:
- unit testing within testng, junit and a simple main java class

This is now effectively covered by Andrew's prototype.

As for the light weight version. This is just another profile/bootstrap 
which is offered to the Launcher.

Most likely I think the Launcher will be a vertical pillar across some 
other components:
- Bootstrap
- Reloaded
- AS
- Embedded

This is because each defines it's own set of configuration items 
extending on the previous.
For example Bootstrap:
${jboss.bootstrap.home.dir} is required by user.
${jboss.bootstrap.conf.url} = ${jboss.bootstrap.home.url}/conf
${jboss.bootstrap.lib.url} = ${jboss.bootstrap.home.url}/lib
${jboss.bootstrap.name} = "bootstrap.xml"
${jboss.bootstrap.url} = ${jboss.bootstrap.conf.url}/${jboss.bootstrap.name}
And Reloaded:
${jboss.reloaded.home.dir} is required by user.
${jboss.reloaded.profile.name} = "default"
${jboss.reloaded.profile.base.url} = ${jboss.reloaded.home.url}/server

etc.

The tricky bit will be assigning the proper properties to the proper 
component while trying to maintain it backwards compatible with what we 
have right now.

Carlo

Bill Burke wrote:
> The difference between embedded and AS is:
>
> * AS controls its classloaders, Embedded doesn't
> * AS is a OS process, Embedded isn't
> * AS is a platform, Embedded is a library
> * AS is a mini-OS.
>
> Our initial push for embedded should focus solely on improving 
> testability of *ALL* jboss components.
>
> For testability there are three key components:
> * Unit testing within maven
> * Unit testing within ant
> * Unit testing within an IDE
> Unit testing within an IDE is a huge piece.  The old JBoss Embedded 
> had that capibility.  They idea of just right clicking in your IDE and 
> running all unit tests within a package and sub-package is just a HUGE 
> productivity boost and something that Spring users are very used to.
>
> I think another key aspect of embedded, specifically in unit testing, 
> will be that it is self-contained.  One jar (or one artifact with N 
> dependencies) is all that is needed.  No configuration files.  It runs 
> out of the box with a set list of components.  In other words all the 
> XML config files are embedded in its JAR.  Then to override specific 
> configs, you either provide properties or XML files that supercede the 
> existing configurations.
>
> After you get this working, the next important thing is improving boot 
> time.  With JMS, I was able to boot up in 3.5 secs back in 2007. 
> Without around 2 secs.  All lot of the time was initializing XML 
> processing according to profiler stats.
>
> Next, a big usecase would be creating lightweight JBoss instances. 
> Currently, AS is like a mini-OS.  You can run multiple versioned apps. 
> Wouldn't it be cool if you could run JBoss as a library and boot it up 
> in 2 secs?
>
> 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.
>> 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
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>