Exit Condition

The year after Fleischer and I finished University we weren’t quite ready to give up Spring Break. So with mischievous intent on the Ides of March, 2004, we stuffed ourselves into an AirBus headed straight for the Gulf Coast of Florida.  It’s like a playground for 20-somethings, and the toys are alcohol and each other.

On the third evening of our stay we happened across a nightclub eager to take our money.  After a couple hours of rubbing up against perfect strangers, I distinctly remember Ludacris’ plea for a “lady in the street but a freak in the bed” piercing through the haze.  This I attribute to a DJ who had apparently put Usher’s “Yeah”[1] on indefinite repeat.

Lady on the street.  Freak in the bed.  Stunning irony, considering that we were hopelessly surrounded by young women showcasing a brand of behaviour typically unfit for public space.  And it occurred to me that though many of my dancing brethren would find some late-night nude adventures, none would be taken home to meet the parents.  Sexy often lacks staying power.  But this guy wants both the Veronica and the Betty[2].

In the world of Enterprise software, there’s a real clash between features desired by developers and those required by business stakeholders.  Throughout the JBoss maturation process we’ve made great strides, especially for an open-source unit, in meeting the demands imposed by the most discerning of powerhouse clients.  Government regulations, security audits, compliance tests – we’ve delivered each one as needed.  And we’ll continue to do so.  That’s reliability.

On the other side of the coin, smaller vendors have been able to differentiate by pushing their application servers geared more to the whims of the community.  Ease of use is a powerful argument which first heralded JBossAS into the market alongside much more well-endowed players, and it fosters a healthy ecosystem where developers love the tools they’re using.  That’s excitement.

Recent surveys have concluded that you, the programmer, want both[3].

It speaks mostly to my unhealthy need for validation that I’ve spent the past few months focused on giving you exactly what you want.

Easy Testing

Unit Tests are fantastic for ensuring that the fine-grained functions of your program work as expected.  Their small scope is simultaneously their advantage and weakness; to truly know how your application will work we must see the interaction of components working in tandem.  This is where Integration Testing comes in.

In the case of JBoss Application Server, this has traditionally involved launching AS as a separate process, deploying your archives, checking your business logic, then shutting down the remote process.  In fact, this is the same approach we take in the AS TestSuite itself, eased through the use of some custom Ant macros.

But in writing the examples for my upcoming EJB 3.1 Book, I’ve found the same problems reported by our users for some time now – it’s cumbersome to test within standalone AS.  What we’ve needed is a simple mechanism to manage the configuration and lifecycle elements of JBossAS and start in the currently-running JVM.

/**
* Configures and starts JBossAS in-process
* @throws Exception
*/
@org.junit.BeforeClass
public static void startJBossAS() throws Exception
{
// Create Server
final JBossASEmbeddedServer server = new JBossASEmbeddedServerImpl();
// Configure
server.getConfiguration().jbossHome("/path/to/JBOSS_HOME")
.bindAddress("myhost.com").serverName("myconfig");
// Start
server.start();
}

This is the result of some prototyping currently underway in the JBoss Embedded project[4].  In fact, it’s the culmination of a bunch of really boring, rote work preparing the AS itself to run in this kind of environment.  I’ve given focus to a clean API and addressing use cases in a concise, predictable fashion.

For the time being, JBoss Embedded will run backed by a traditional JBOSS_HOME installation.  In the future we’ll provide a single JAR distribution which will be the sole dependency in launching the server.  Also on the roadmap is a Maven2 Plugin wrapper to tie the server launch into the Maven lifecycle (such that you won’t have to manually code startup/deploy/shutdown in your tests).

At the moment, I’ve verified the following works:

* EJB3 Stateless Session Beans
* Servlets / JSPs
* Java Message Service (JMS) and EJB3 Message-Driven Beans
* Persistent DataSources and EJB3 Entity Beans (some caveats at press time)
* Local EJB invocations pass by reference
* Blocking MDBs to wait for them to process messages

You can even take advantage of launching straight from the IDE, for instance in Eclipse’s JUnit Integration:

This has gotten a bunch of the other JBoss Core Developers all excited, so we’re pushing forth full steam ahead to cut an early Alpha alongside the next JBossAS release.

Virtual Archives

Alongside the server elements of Embedded is the need to provide some tools to shorten the test lifecycle.  A particularly nagging point is introduced by the packaging requirements of the various Java Enterprise Edition specifications; classes and resources must be assembled in a very specific arrangement, and this provides some implicit metadata to the server during deployment.  The problem is, writing build scripts is a real pain when you just want to see your stuff working.

We’re therefore including the notion of a “VirtualArchive”, which is used to declaratively assemble bits and pieces scattered about the filesystem into one fake unit.  You determine the structure of the archive, and pass it along to the server.

final VirtualArchive archive = VirtualArchiveFactory.createVirtualArchive("slsb.jar")
.addClasses(OutputBean.class,OutputLocalBusiness.class);
log.info(archive.toString(true));
server.deploy(archive);

The verbose toString() form helps with debugging:

slsb.jar - 0 bytes
slsb.jar/org - 0 bytes
slsb.jar/org/jboss - 0 bytes
slsb.jar/org/jboss/embedded - 0 bytes
slsb.jar/org/jboss/embedded/testsuite - 0 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep - 0 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep/ejb3 - 0 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep/ejb3/slsb - 0 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep/ejb3/slsb/OutputBean.class - 844 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep/ejb3/slsb/OutputLocalBusiness.class - 312 bytes

This is actually my favorite feature of Embedded thus far.  The amount of time you can save by putting off the composition of JAR/EAR/WAR files is astounding, and it also opens the doors to quick testing specific EJBs in isolation.

Next Steps

From here we keep plugging.  I’m assembling a crack team of contributors to help with tests, patches, and feature development.  The projects themselves are fairly self-contained and well-documented, so diving in shouldn’t be much a problem.  Contact me directly and I’ll point you to some low-hanging fruit.  Make some good patches and I’ll hook you up with commit access.  If you can hack it, hack on our stuff.

Once AS has a formal release I’ll shout again with instructions for using it as detailed above.  I encourage you all to be proactive in downloading and giving this all a spin.  It’s the feedback from early adoptors which will be critical to the success of these projects.

And so it is for JBossAS.  On the street, we’ve already got the cred.  But behind closed doors in shops around the world, we want to get you off quickly.

Lady on the street.  Freak in the Embed.

S,
ALR

References:
[1] http://en.wikipedia.org/wiki/Yeah!_%28Usher_song%29
[2] http://en.wikipedia.org/wiki/Archie_Comics
[3] http://www.jboss.org/community/wiki/JBossASTop10
[4] http://www.jboss.org/community/wiki/JBossEmbedded