8:53 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com