[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

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