6:01 p.m.
Over the past few weeks I've been rebuilding the bootstrap component as
a true project, with the following goals:
* Tested
* User-friendly API
* No reliance upon a full AS
* Base for AS Main, AS Embedded, Standalone Project Runtimes
SVN: http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/
JIRA: https://jira.jboss.org/jira/browse/JBBOOT
There are a few subprojects:
* spi : Plain Server SPI
* spi-mc : Adds MC-aware support to the Server (ie. getKernel())
* spi-as : Adds AS-specific constructs such as JBOSS_HOME,
jboss.server.home.url, etc.
* impl-base : Plain base implementation of server, configs, etc
* impl-mc : Base implementation for MC-based servers
* impl-as : The full AS bootstrap
Contrary to the older implementation (which I'm calling "legacy") are
the following:
* jboss-bootstrap now leaves ClassLoading (mostly) out of scope.
Clients should be ensuring that the server is loaded/started under an
appropriate ClassLoader. This may take the form of a test classpath set
up by Maven, Ant, or a specialized URLClassLoader to define exactly what
you'd like visible. This opens up using bootstrap to a much wider range
of deployment scenarios.
* The new implementation is not API-compatible. I drew a line in the
sand to create a new SPI which should be ultimately easier to
use/understand.
* jboss-bootstrap no longer supports the exit/halt operations. Whoever
starts the server is responsible for stopping it. To kill the VM should
not be a concern of the server, as the there may be other operations
running upon full shutdown (like tests, or a web container, or even
another server).
The patch to bring this into AS has been under development in:
http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x_BootstrapLegac...
...and I plan on bringing this into Branch_5_x once both 5.1.0 is cut
and I can verify no regression in the AS TestSuite.
*Issues*
The following are outstanding, possible points of discussion:
1) Non-daemon Threads after AS shutdown keeping VM active
https://jira.jboss.org/jira/browse/JBAS-6919
If launched from AS Main, server shutdown should allow the VM to exit.
The presence of non-daemon Threads hanging around after the shutdown
lifecycle has existed prevents this. Please take a look at the thread
dump I've attached to the JIRA and ensure your project is not
contributing to the remaining Threads. Subtasks referencing JBAS-6919
should be forthcoming.
2) Static set of JAR names for boot lib, shouldn't it be everything in
$JBOSS_HOME/lib?
https://jira.jboss.org/jira/browse/JBAS-6920
AS Main declares a set of JARs to be included on the boot ClassPath. Is
my understanding correct that *everything* within $JBOSS_HOME/lib is
eligible? If that's correct, I'll clear out /lib of everything that's
not needed and make the logic scan the dir and add everything in there.
3) JMXKernel shutdown calls Runtime.exit Hack
https://jira.jboss.org/jira/browse/JBAS-6916
Because I've taken Runtime.exit out of the concern of bootstrap, and
because of the non-Daemon Threads after shutdown, I needed to add this
hack to JMXKernel to tell the whole VM to go down.
4) I'm doing this backwards.
Typically I'd merge into trunk *before* Branch_5_x, but I want this in
the open and getting tested for as long as possible before the next few
AS releases. Ping me if this is a problem.
*Roadmap*
The bootstrap subprojects are currently at 0.1.2. Looking forward:
1.0.0-alpha-x : Once merged into AS Branch_5_x
1.0.0-beta-x : SPI freeze
1.0.0 : Formal release
*What Can it Do For You?*
The MCServer itself is especially handy for testing your subproject in
standalone fashion. The JCA Standalone Container, for instance, is to
be built atop the MCServer. The process is:
1) Create a new Server
2) Configure it, pointing it at your main bootstrap
3) Call start()
You might find that this eases in your project's unit testing and
enables you to cut dev time by cutting reliance upon the AS TestSuite.
@see
http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-mc/s...
*Where are the Docs?*
I need to make a few Wiki pages; I'll email the list with locations when
I do. Until then everything is JavaDoc'd and should be self-documenting
via the unit tests. Or ask me on Design of POJO Server Forum.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com