I been here for years. Suffering through inane arguments claiming you don’t need transactions or security or a decent runtime which integrates messaging, database connectivity, and clustering. Let’s start by each making some concessions. I’ll go first.

Java EE Application Servers were tougher on the development lifecycle than POJO frameworks. There, I said it.

Now your turn. I’ll even help you.

You’ve been lazy.

Plain and simple. Lazy. You don’t want to suffer through an involved test setup. You don’t want to write code that fires up some container, you don’t want to switch focus away from your development, you don’t want to deal with Frankenstein’d build setups. Forget that you’re ignoring all the benefits of a proper enterprise environment. So you either punted on Java EE altogether, or just skimped on testing that your stuff works. You’re L-A-Z-Y lazy.

And you’re lazy because you’re smart. You know that crap is getting in the way of your real job – to write business logic. And test logic. Not plumbing and scaffolding. That’s my job.

Luckily for us both, I’m not lazy. And neither is my team. We’ve worked very hard to give you what you want. That’s my job, too.

Over the past two years we’ve taken a hard look at the shortcomings of Java’s Enterprise Platform. And generally-speaking, the pain points have fallen into one of three categories:

* Startup/Deployment/Runtime Performance
* Developer Usability
* Administration and Management

Well holy shit, turns out those aren’t shortcomings of the Platform at all. Nowhere in the specifications does it dictate that an application server should be slow or unwieldy. So we set out to make damn sure that you get the best user experience possible out of anything branded with the JBoss logo.

So we started from scratch. Quite literally, a blank repository for JBoss AS. And then structured the scaffolding bits to work around 7 key problem areas.

Startup should be fast. Deployment should be fast. After all, we’re doing these tasks pretty regularly as part of the development lifecycle. So we kept a fine focus here, and delivered something which approximates the following results:

With flushed filesystem disk cache in blue; using FS cache in red

Not bad.

Quite simply put, two objects cannot occupy the same space at the same time. Take the following case: The Application Server ships with Hibernate version X in order to provide a JPA runtime. Say your deployment wants to use version Y. In a traditional hierarchical classloading model, classloading delegation would take over and the deployment would actually see the server’s version of these classes, which probably isn’t the intended move. We’ve offered configurable classloading in the past, sure, but this time we’ve moved to a truly modular system which isolates visibility by default. It’s called JBoss Modules, and it’s slimmer than systems like OSGi by limiting scope to fast (O(1)), concurrent classloading and leaving concerns like service installation elsewhere (like our OSGi integration project).

RAM consumption. It just needs to be curbed. Especially when you consider this cloud movement we’re having – consuming fewer resources very simply means fewer VMs, and this directly affects your bottom line. So in line with the minimalistic approach we’ve taken with ClassLoading, we’ve introduced the Modular Service Container to act as the kernel wiring together the services which comprise JBoss AS. It’s not a general-purpose programming model; it’s an intentionally feature-restricted state machine with, again, a huge emphasis on concurrency.

This is likely the biggest gap in Java EE development. The development lifecycle has us doing:

• Code code code
• Run a build
• Start a server
• Deploy the stuff from our build
• Run our tests
• Repeat

It’s disgusting. And we’ve got a way to take us to this:

• Code code code
• Run our tests

So what we built was the testing platform Arquillian.

We abstract out all container interaction from the test logic. Leaving us to write only:

@RunWith(Arquillian.class)
public class GreeterManagedBeanTestCase {
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class)
.addClass(Greeter.class)
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
}
@Inject
Greeter greeter;
@Test
public void should_greet_earthlings() throws Exception {
String name = "Earthlings";
Assert.assertEquals("Hello, " + name, greeter.greet(name));
}
}

What’s best is that Arquillian relies on no build or IDE plugins; if you can run JUnit or TestNG, you can run Arquillian. From the command-line, from the IDE.

This will be the topic of another post I’ll write in this space, to be released shortly.

Prior versions of the Application Server have had configuration-per-subsystem, which has amounted to a series of XML files scattered about the installation. We’ve unified these into a singular entry point, with natural-language syntax like:

<socket-binding-group name="standard-sockets" default-interface="public">
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jmx-connector-registry" interface="management" port="1090"/>
        <socket-binding name="jmx-connector-server" interface="management" port="1091"/>
        <socket-binding name="jndi" port="1099"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
</socket-binding-group>

So there’s no more relying upon implementation internals for configuration. And everything is backed by XSD, so you’ll get helpful IDE completion.

A new concept in JBoss AS7 is the notion of a Domain, a series of instances which may be managed together through one process called the Domain Controller. In effect this provides one-stop shopping to configure independent servers and manage their lifecycle, limiting the maintenance burden especially for administrators of larger server farms. And helping you to keep. Costs. Down.

And as always, we aim to provide you with a host of killer services, out of the box. Java EE and beyond.

• Hibernate: JPA Provider
• RESTEasy: JAX-RS
• Infinispan: Data Grids
• Snowdrop: Spring Integration
• JBoss OSGi
• TorqueBox: Ruby on the JBossAS Runtime
• Weld: JSR-299 / Contexts and Dependency Injection

JBoss AS made its name in being the developers’ choice. Because it’s free, and it doesn’t suck.

So don’t call it a comeback.

S,

ALR

I patronize the Boston Sports Clubs. Every month they suck cash out of my checking account; in return I get to say I belong to the gym. My membership keychain promotes me as a fit young professional, and I’m comfortable with this positioning. False advertising at its finest.

But every now and then I get ambitious and join the ranks of the walking biceps intent on whipping my programmer’s physique into some presentable form. Jocks on all sides gruntily hoist iron plates into the air as they mainline Eminem straight from iPod to ear. Dudes, followed by mirrors reflecting an infinite row of yet more dudes. And they all cry the same anthem: “No pain, no gain”.

This is some BS, but I don’t think the weight floor is a proper venue for some lesson on the merits of working “smarter not harder”. Brute force or go home.

So I went home.

You know what I’ve found painful? Writing integration tests for application servers. I’ve a clear history towards promoting JBossAS over something more lightweight[1], and in my opinion any non-trivial application that doesn’t take advantage of a decent runtime environment is a bad joke masquarading as an enterprise-class solution. But I couldn’t get around the argument that writing decent integration tests was a time-consuming and frustrating endeavor, until now.

Some time back[2] I’d reported on the progress made in prototyping an Embedded API for the JBoss Application Server, and we’re now at our first early-access release compatible with JBossAS 6.0.0.M1[13]. For the time being these Embedded libraries are shipped as an extension to AS, and I expect that after some community feedback we’ll push out a few more releases before locking things down and eventually bring everything into the AS distribution.

Now we’re all very proud to reintroduce JBoss EmbeddedAS[3] 1.0.0-alpha-1.

What’s in this Release

Very simply, this gives you the API hooks to create, configure, start, deploy into, and stop the server in a POJO environment. Slap your favorite testing framework into the mix and integrate with your build system, and you’re on the path to automated integration tests.

The syntax is so easy, it’s barely worth covering. Our API Guide[4] should touch upon the more common use cases.

@BeforeClass
public static void startEmbedddedAS() throws Exception
{
  // Make Server
  server = JBossASEmbeddedServerFactory.createServer();
  // Configure
  server.getConfiguration().serverName("all")
    .jbossHome("/path/to/$JBOSS_HOME");
  // Start
  server.start();
}

@AfterClass
public static void stopEmbeddedAS() throws Exception
{
  // If exists and started
  if (server != null &&
     server.getState().equals(LifecycleState.STARTED))
  {
    // Shutdown
    server.shutdown();
  }
}

Testing is now a matter of assembling resources together into a unified view, then deploying into the server. Currently supported are Files, URLs, and ShrinkWrap[14] archives, though you’re welcome to use your own Deployable implementation. As an example:

@Test
public void testStatelessSessionBean() throws Exception
{
  // Make a ShrinkWrap archive
  final String name = "slsb.jar";
  final JavaArchive archive = Archives.create(name, JavaArchive.class).
    addClasses(OutputBean.class,OutputLocalBusiness.class);
  // Deploy
  server.deploy(archive);
  // Test
  final OutputLocalBusiness bean = (OutputLocalBusiness) NAMING_CONTEXT.lookup
    (OutputBean.class.getSimpleName()
    + JNDI_SUFFIX_LOCAL_BUSINESS);
  final String output = bean.getOutput();
  Assert.assertEquals(OutputLocalBusiness.EXPECTED_OUTPUT, output);
  // Undeploy
  server.undeploy(archive);
}

Because the server is within the same JVM as the tests, we can now:

* Invoke upon EJB3 local views
* Reliably test asynchronous invocations (eg. by setting a Barrier in an EJB3 Message-Driven Bean)
* Test operations which use pass-by-reference
* Gain access to the server’s internal Microcontainer Kernel

Examples of each are in the EmbeddedAS Integration Testsuite[5].

One interesting complication of running the server in a host JavaSE environment is that you’ll have to make some choices regarding the ClassLoading model used. If your test relies upon AS internals (ie. uses Microcontainer directly), it’s likely that you’ll need the entire AS dependency set upon your application classpath; we provide more information and suggested instructions for this technique here[6]. However, this imposes a great number of libraries be passed into your test process via “-classpath”, and it’s likely you’ll want to opt for a slimmer boot profile. If you’ve got good separation and call upon the EmbeddedAS APIs only, you may pull in the remaining runtime dependencies via a “JBossHomeClassLoader” upon server creation; more details here[7].

Looking Forward

At the moment we’re offering EmbeddedAS as a preview for community input, and openly encourage your participation in our forums[8]. The current links upon the Wiki are a bit Maven-centric, though folks preferring to set up the test runtime via Ant should be able to do so as well – feel free to add to the documentation.

One of the current limitations is that EmbeddedAS 1.0.0-alpha-1 will be released only through the JBoss Maven Repository[9]. It may still be manually downloaded, but in subsequent releases we’ll also provide a unified ZIP (or move everything into AS itself).

Already we’ve received interest in and are considering a Maven2 Plugin similar to Cargo for launching the server and deploying artifacts. This could remove the need to manually code these steps.

Contributions by Aslak Knutsen and the Arquillian[10] project aim to abstract out the server creation/start/deployment steps as well, instead making way for syntax like:

@RunWith(Arquillian.class)
public class GreetingManagerTest
{
  @Deployment
  public static JavaArchive createDeployment()
  {
    return Archives.create("test.jar", JavaArchive.class)
      .addClasses(
      GreetingManager.class,
      GreetingManagerBean.class);
  }

  @EJB
  private GreetingManager greetingManager;

  @Test
  public void shouldGreetUser() throws Exception
  {
    String userName = "Devoxx";
    Assert.assertEquals(
      "Hello " + userName,
      greetingManager.greet(userName));
  }
}

Adrian Cole of jclouds[11] has also expressed a desire to investigate EmbeddedAS as a provisioning engine for transporting workflows. I hope to continue these discussions looking forward.

In the meantime, glance over our Wiki and give everything a spin. We’ve got a neat screencast[12] and interview, Dimitris[15] and Jason[17] have nice summaries of AS 6.0.0.M1, and Brian discusses[16] some new clustering features as well.

We’ll offer bug fixes, feature enhancements, and API changes in subsequent releases to be compatible with the latest available release of JBossAS, starting with 6.0.0.M1.

What we can make easier, we will. I’ve a low tolerance for all things unpleasant, so no pain, no pain.

S,

ALR

[1] http://exitcondition.alrubinger.com/2008/01/05/heavy-is-a-perception/
[2] http://exitcondition.alrubinger.com/2009/07/29/were-gonna-be-good-embed/
[3] http://www.jboss.org/community/docs/DOC-13843
[4] http://www.jboss.org/community/docs/DOC-14437
[5] http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk/testsuite/src/test/java/org/jboss/embedded/testsuite/ServerIntegrationTest.java
[6] http://www.jboss.org/community/docs/DOC-14441
[7] http://www.jboss.org/community/docs/DOC-14447
[8] http://www.jboss.org/index.html?module=bb&op=viewforum&f=265
[9] http://repository.jboss.org/maven2/org/jboss/embedded/
[10] http://www.jboss.org/community/docs/DOC-14376
[11] http://code.google.com/p/jclouds/
[12] http://java.dzone.com/videos/embedded-jboss
[13] http://www.jboss.org/jbossas/downloads/
[14] http://jboss.org/shrinkwrap/
[15] http://dandreadis.blogspot.com/2009/12/jboss-as-600-m1.html
[16] http://bstansberry.wordpress.com/2009/12/02/clustering-features-in-jboss-application-server-6-0-0-m1/
[17] http://in.relation.to/Bloggers/IntroducingJBossAS600M1

The holiday season is approaching.  Since Sam Summer turned into Sam Oktoberfest[1] I’ve seen a frightening array of tinsel slowly invade area department stores, and I know that some dreaded chorus of electronic carols cannot be far behind.  But it’s not the commercialism that concerns me.  It’s not the burden of shopping, the endless pursuit of parking, nor the $400 doll that some daytime talk show turned into the must-have accessory for our nation’s toddlers.  Once I’ve accounted for everyone on my “Good” list…it’s time to sit down and do the wrapping.

The scissors.  The tape.  Silly cards that unnecessarily explain, “Hey, this is a gift.”  It’s not enough that I’ve spent my time considering what you’d like before building or acquiring it; you, princess, need a shiny cover too.  Ungrateful bitch.

Application servers are similarly prissy.  By specification, they might not have a clue what to do with your programs unless you’ve got cutesy little descriptors littered exactly where they’re expecting.  Annotation support introduced in JEE5 helps by reducing the amount of boilerplate XML, but there’s some other implicit metadata within archives.  ClassLoading scope says that every resource within a bundle will be able to see each other, and atomicity guarantees that we’ll be treated as a singular deployment.

Traditionally, we have a build process responsible for packaging our resources in expected form.  The problem this presents is that our development cycle must look like:

* Code
* Build Step – Compilation
* Build Step – Packaging
* Test

In practice, most IDEs offer incremental compilation which we’ll often overwrite or ignore during the build process.  But the most egregious flaw in this setup is the context switching it imposes; you must redirect your attention from the code to run a build.  I want to code, test, code, test.  Because I’m a very poor coder prone to making mistakes, I test nearly every method for coverage as it’s written.

Scripting the build is a PITA as well.  I’m constantly looking at Ant or Maven documentation to figure out the correct syntax.  Again, because I’m a poor coder and have low retention for rote tasks.  I don’t think it’s a tremendous leap to assume that Java programmers are most proficient in Java.  Any context switching we do is distracting.  Code, test, code, test.

So we should be writing our tests in Java, without any dependencies on a build process.

The ShrinkWrap[2][3] project enables you to do just that.

// Make an archive; put some classes in there
JavaArchve archive = Archives.create("myejb.jar", JavaArchive.class).addClasses(MyLocalBusiness.class, MyBean.class);
// Deploy into EmbeddedAS
server.deploy(archive);
// Log out the full contents in an "ls -l" -type output
archive.toString(true);
// Export to an InputStream in ZIP/JAR format
InputStream in = archive.as(ZipExporter.class).exportZip();

Ultimately, I wanted to continue the support for “manual deployment of archives” pioneered by Bill Burke[4] within EmbeddedJBoss[5].  Previously we used to provide this by leveraging JBoss Virtual File System (VFS)[6] and its in-memory files.  After some further consideration we were able to skip *all external library dependencies*.  We have a great mission and featureset:

* Intuitive, clean API
* Export to ZIP/JAR or exploded directory
* Import from ZIP/JAR or exploded directory
* Typesafe specialization
* Domain-specific language extensions (To declare web.xml servlet metadata for instance; Under development)

From an administrative standpoint, I can’t be prouder of how this project was run.  We took good ideas from history, added some of our own, and collaborated in public with a couple of talented community contributors.  Aslak Knutsen[7] and John Bailey[8] in particular gave a lot of their thought and time into ironing out each feature and public interface.  We have a testsuite with strong coverage and have used the excellent FindBugs[9] code analysis framework to catch things we didn’t.  Jesper Pedersen[10] of JBoss JCA fame gave us a great peer review.  And now ShrinkWrap is a first-class citizen in the upcoming release of EmbeddedAS, a new API for the JBoss Application Server.  More on that later; watch this space.

Looking forward, I’d love to see some more community involvement; for instance I’ve invited the Glassfish team to consider supporting us in their embedded server.

In the meantime, we’ll be building out our Wiki and documentation.  Early-access release 1.0.0-alpha-2[11] was just cut a couple days back, so it’s not too late to give some input before we freeze the APIs[12].  There’s virtually no barrier to entry here; if you know the core JDK you’ll be able to join our development team.

So consider this my holiday present to you.  Wrap it yourself.

S,

ALR

[1] http://en.wikipedia.org/wiki/Boston_Beer_Company#Seasonal_beers
[2] http://jboss.org/shrinkwrap
[3] http://www.jboss.org/community/docs/DOC-14138
[4] http://bill.burkecentral.com/
[5] http://www.jboss.org/community/docs/DOC-9685
[6] http://java.dzone.com/news/jboss-virtual-file-system
[7] http://jboss.org/community/people/aslak
[8] http://jboss.org/community/people/baileyje
[9] http://findbugs.sourceforge.net/
[10] http://relation.to/Bloggers/Jesper
[11] http://www.jboss.org/shrinkwrap/downloads.html
[12] http://docs.jboss.org/shrinkwrap/1.0.0-alpha-2/api

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:

JBossAS Embedded in Eclipse/JUnit

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

We used to throw the best parties in our Coolidge Corner[1] bachelor pad.  The recipe was simple: we’d blast an eVite to the city of Boston, pick up a keg of Good Decision[2], break out the Beirut[3] table, and ask the local police to turn a blind eye.

In the midst of one of our more smashing affairs, conversation turned to concurrent polygamy and if any of us were fortunate enough to have practiced the art firsthand.

Josh had.  Of course, Josh had.

And he offered us this advice: “You don’t go looking for it.  It’s given to you, so don’t ask questions and just take advantage of the opportunity.”

Don’t you know it, opportunity knocked upon my roommate Jon’s door not three hours later.  With a couple of part-time models.  Two models at the same time.

While the next morning’s brunchtime report was entertaining enough, my inner geek preferred to explore how some of the same themes might be applied to component architecture.

Models:
* Are not necessarily mutually exclusive
* Should be encouraged to focus on their own domains
* May share in some concerns, each from a different angle
* Combined are worth more than the sum of their parts

Shoot forward a few years, when an enabling technology caught up with my musings in the form of JBoss Microcontainer[4].

My first impression of MC was that it was “another DI Container”.  And at its core, sure, it provides the kind of POJO autowiring that we’ve come to expect from this class of framework.  Over the past year, however, I’ve come to appreciate MC for its extensibility, a truly differenciating characteristic from other offerings.

DI is all very nice, but I’m accustomed to having some greater utilities available to create my runtime environment.  A quick glance at the MC feature list boasts Virtual Deployment Framework (VDF), a filesystem abstraction (VFS) and aspectized classloading facilities.  Armed with these, I was set to kick the tires in hopes of discovering some deficiencies in the design and thus gaining bragging rights over Ales[5].

Mission: Provide @EJB injection into MC Beans

In short, I want MC Beans to be able to inject references to EJB3 proxies.  This will be our integration point for interacting with EJB from MC-based Services.

MC applies a metadata-collecting vistor to beans that are installed, and this is passed along to an AnnotationPlugin[6] whose responsibility is to apply the requisite info to the visitor.  By implementing an AnnotationPlugin to handle javax.ejb.EJB, we’ve got our hook[7].  This process is eased by abstract support from FieldAnnotationPlugin, and the main goal here is to supply a ValueMetaData describing the injection value.:

/**
* Create @EJB value meta data.
*
* @param annotation
* @return @EJB metadata
*/
@Override
protected ValueMetaData createValueMetaData(FieldInfo propInfo, EJB annotation)
{
// Get properties from the annotation
String beanName = annotation.beanName();
String beanInterface = annotation.beanInterface().getName();
String mappedName = annotation.mappedName();
// Supply beanInterface from reflection if not explicitly-defined
if (beanInterface == null || beanInterface.equals(Object.class.getName()))
{
String reflectType = propInfo.getType().getName();
beanInterface = reflectType;
}
// Create a reference
EjbReference reference = new EjbReference(beanName, beanInterface, mappedName);
log.debug("Found @EJB reference " + reference);
// Return a new ValueMetaData w/ the reference
return new AbstractEjbReferenceValueMetadata(this.getResolver(), reference, this.getNamingContext());
}

The “EjbReference” above is a value object used by the EJB3 Reference Resolver, responsible for finding the JNDI Name to which a reference is bound.

The return value is AbstractEjbReferenceValueMetadata[8], an implementation of ValueMetaData able to:

1) Declare a dependency upon the JNDI target value.  This ensures our MC Bean will not deploy until the referenced EJB has
2) Obtain the EJB Proxy from JNDI so that it may be injected

Simple enough.

From here, the only thing left to do is let MC know that it should consider our new AnnotationPlugin upon installation of new beans.  For this task I’ll create a simple POJO[9] which, installed, will alter MC’s behaviour.  The key here is in the lifecycle “@Start”:
@Start
public void start() throws Exception
{
// Install the BeanAnnotationAdapter w/ callback to add annotation plugins on install
BeanAnnotationAdapter beanAnnotationAdapter = BeanAnnotationAdapterFactory.getInstance()
.getBeanAnnotationAdapter();
String beanAnnotationAdapterBindName = MC_NAMESPACE_EJB3 + "BeanAnnotationAdapter";
BeanMetaDataBuilder bmdb = BeanMetaDataBuilder.createBuilder(beanAnnotationAdapterBindName, beanAnnotationAdapter
.getClass().getName());
bmdb.addMethodInstallCallback("addAnnotationPlugin");
bmdb.addMethodUninstallCallback("removeAnnotationPlugin");
try
{
this.getKernel().getController().install(bmdb.getBeanMetaData(), beanAnnotationAdapter);
}
catch (Throwable e)
{
throw new RuntimeException("Could not install " + beanAnnotationAdapter, e);
}
}
Here we get at the BeanAnnotationAdapter and install it into the KernelController along with some callbacks to automatically add AnnotationPlugins when they, in turn, are installed.  From here on out, all we need is to throw EjbReferenceAnnotationPlugin into MC.

I’ve tracked this feature[10], along with passing integration tests in the EJB3 TestSuite[11].

Unfortunately, I’m left with nothing to hold aver Ales’ head as MC provided me, as a framework developer, with all the tools needed to extend the provided groundwork.  In fact, I’m even at a deficit because I needed to consult the Microcontainer Users’ Forum[12] for some suggestions.

I’d like some input from application developers – in what situations would you like to call an EJB from a POJO?  Managed objects within Microcontainer act as singletons within the confines of the system, so there should be plenty of occasions to call upon a pooled/cached distributed component.  This is the goal we address by providing integration between component models.

Because nothing catches on without a proper title, I’ll name our approach right now: Concurrent Polyforma.

So now we’ve put JBoss MC to a real-world test, proving that it can wrap your favorite model.  As an additional exercise, I also did this quite literally:

Caylin Loves MC

This is how we’ll help you bridge two models.  You just can’t Eiffel Tower[13] them.

S,
ALR

[1] http://en.wikipedia.org/wiki/Coolidge_Corner
[2] http://www.beeripedia.com/index.php/Samuel_Adams
[3] http://en.wikipedia.org/wiki/Beer_Pong
[4] http://www.jboss.org/jbossmc/
[5] http://www.jboss.org/community/people/alesj
[6] http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kernel/src/main/java/org/jboss/kernel/plugins/annotations/AnnotationPlugin.java
[7] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/mc-int/src/main/java/org/jboss/ejb3/mcint/metadata/plugins/EjbReferenceAnnotationPlugin.java
[8] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/mc-int/src/main/java/org/jboss/ejb3/mcint/metadata/plugins/AbstractEjbReferenceValueMetadata.java
[9] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/mc-int/src/main/java/org/jboss/ejb3/mcint/annotationadaptor/AddAnnotationPluginOnBeanAnnotationAdaptorCallbackService.java
[10] https://jira.jboss.org/jira/browse/EJBTHREE-1624
[11] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/testsuite/src/test/java/org/jboss/ejb3/test/ejbthree1624/
[12] http://www.jboss.com/index.html?module=bb&op=viewforum&f=228
[13] http://www.urbandictionary.com/define.php?term=eiffel%20tower&defid=1242963

2002 was the year of Bad Ideas.

An overly-anxious United States Congress granted “immediate emergency powers”[1] to the President, resulting in war[2].  WorldCom and United Airlines both went Chapter 11.  Journalist Daniel Pearl was executed by terrorists in Pakistan.[3]  Two yahoos sniped at civilians in Washington, DC.[4]  And Britney cheated on Justin.[GASP]

Amid the muck Rod Johnson quietly released “Expert One-on-One J2EE Design and Development”[5], and it was chock-full of Good Ideas.  Among them:

* The contract between the bean provider and the container was too verbose
* The remoting model imposed bulky access
* Aspect-oriented programming should be used to apply orthogonal concerns
* Entity Beans sucked
* Testing business logic contained in EJBs was difficult
* EJB inhibited good OO design due to its API restrictions

I can see why the Spring movement was seen as such a breath of fresh air to developers sick of coding Local, Remote, Local Home, Remote Home, and Implementation classes for what might be a trivial service.  The community owes a debt of gratitude to the assertions presented by Rod & co.

To underscore how correct many of these anti-EJB claims were, the Expert Group behind JSR-220[6] independently came to many similar conclusions, and after 3 years of work released the EJB 3.0 Specification in May of 2006.

Bringing simpliciation to the standard was not applauded by the Spring-a-lings.  “[They believe] the same thing Wednesday that [they believe] on Monday, no matter what happened Tuesday.”[7]

Which is fine.  Really, conflicting views within the industry should be embraced as its the consumer who will benefit in the long run from a variety of options.

But today I read something disturbing, taken straight from the Product Page of the SpringSource tc Server[8]:

“The Spring container has replaced the EJB container in a majority of enterprise Java applications and is now the de facto standard for enterprise Java.”

Oh, fuck you with a rake.

I’ll break this down into two components:

1) Spring has replaced EJB in the majority of JEE outfits
2) Spring is the standard (in practice, not law) for Enterprise Java

This evokes memory of some poorly-conceived graphs and analysis posted by Rick Hightower[9] and later covered by InfoQ[10] in 2006, where job postings and brain-dead search terms drew the picture that EJB as a platform was flaccid in comparison with Spring’s reign.  Ignoring for the moment that we’re extrapolating fact from subjective assumptions, it’s only proper that I present some current numbers using relatively impartial queries:

Here we’ve got Google search terms.  Note the top three.

Looks like “J2EE” is still a very popular job posting, despite being a deprecated grammar.  “EJB 3″ doesn’t even show on the map if charted.

What I’d really love to see are some third-party analysts’ metrics.  Or maybe the Spring Flingers can back these claims up with hard data. Until then, I’m relegated to hold the position that EJB is maintaining its dominance[11].  Not to mention that even today JEE hasn’t yet shaken the bad blood accumulated in the days of the EJB 2.x spec, when DI and AOP were the new hot toys.

Or maybe I’m being unkind.  After all, if the community was aware that every single bullet in the Spring mission statement[12] was addressed by a specification and backed by a series of compliant implementations, they’d have no business left.  What’s the value-add to a company that is proud to do little more than aggregate other proven technologies?

Again, Springers mostly have it right.  Simplicity is great.  But it doesn’t have to come at the expense of EJB anymore; we’ve adapted, you should too.  If Pluto can stop being a planet, surely you guys can stop being dicks.

S,
ALR

[1] Star Wars Episode II: Attack of the Clones
[2] http://en.wikipedia.org/wiki/Iraq_Resolution
[3] http://en.wikipedia.org/wiki/Daniel_Pearl
[4] http://en.wikipedia.org/wiki/Beltway_sniper_attacks
[5] http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764543857.html
[6] http://jcp.org/en/jsr/detail?id=220
[7] Stephen Colbert in reference to George W. Bush, 29 April 2006, http://en.wikipedia.org/wiki/Stephen_Colbert_at_the_2006_White_House_Correspondents%27_Association_Dinner
[8] http://www.springsource.com/products/suite/tcserver
[9] http://jroller.com/RickHigh/entry/stack_of_choice_jsf_hibernate
[10] http://www.infoq.com/news/2006/11/job-trends-ejb3-spring
[11] http://bill.burkecentral.com/2008/02/13/ejb-maintains-its-dominance/
[12] http://www.springframework.org/

Avid readers will note that I’ve been silent for some time here.  It’s a new philosophy I’ve adopted: “Put Up or Shut Up“.

Anyone monitoring JBoss EJB3 source control activity over the past couple months has noticed around-the-clock commits from our team.  4AM on a Sunday.  Midnight on a Thursday.  Hell, I’ve even been known to do some work during business hours when things are really cranking.

All of this has been dedicated to one goal: JEE5 Compliance of the JBoss Flagship project, Application Server 5.  And just last week, we pushed out binaries capable of making some 27412 Integration Tests maintained by Sun turn green.

Sacha and Dimitris have already spoken to the ongoing status and importance of this milestone, so I won’t reiterate their points.

But I’m not celebrating yet.

Compliance is a prerequisite.  It cedes vendor lock-in, promotes uniformity among programmers the world over, and sets a contract for what application developers may expect from their runtime.

And I think we’ve reached a point where you should be able to take that all for granted.  Now we go back to the regularly-scheduled, which in JBoss’ case is innovation and love for the community.

The best place to start is under the hood.

Get Out of the Application Server

We invested heavily in this one.  Simply put, we moved the EJB3 implementation out of the Application Server source tree, created APIs/SPIs where coupling was required (separating contract from implementation) and set proper dependencies.  This gives EJB3 a life of its own and unbinds it from the AS release cycle.  While there’s still some work to be done in this regard, the end goal is twofold:

1) Release EJB3-only updates to AS with regular frequency
2) Don’t require AS to run EJB3

Componentize

@see http://en.wikipedia.org/wiki/Software_componentry

The idea here is to separate the logical moving parts into isolation; this way we don’t:

1) Mix concerns
2) Allow bugs in one area to pollute another

…while we do:

1) Enjoy small, easily-maintainable projects
2) Promote Unit Testing (in the true spirit of “Unit”, not to be confused with “Integration” or “Acceptance”)

Unit Test

We’ve always tested, by means of an integration testsuite that takes ~90 minutes to complete.

But componentization has given us the opportunity to create small, focused, and quick Unit Tests.  Currently we’re at 207 of ‘em, which run in about 5 minutes locally or 8.5 minutes from a freshly checked-out CI server.

Baby, that shit’s textbook.  Better curves than a pinup girl.

All told, we’re beginning to see the concrete benefits of these investments, which translate into accelerated, reliable development.

JEE Compliance is like marriage – not a conclusion, but a beginning.  I just hope compliance doesn’t mean you stop having sex.

S,
ALR

My childhood home really had it all.

Nice deck overlooking Callahan State Park, bicycle-friendy cul-de-sac, open living room with French windows, eat-in kitchen, and suburban zip code.

For years, it even had a hugeass Oak tree that seasonally fired acorns at your skull if you dared retrieve the mail.

So my parents never moved, and that’s why I’m friends with the same fuckers I knew back in preschool. I guess the house just worked for my folks.

And it must have worked for my neighborhood’s developers too, because don’t you know – they put three-hundred just like it next door.

[STAMP] 7 Rolling Drive [STAMP] 9 Rolling Drive [STAMP] 11 Rolling Drive …

Clearly, the economies of scale provided by a reproducible build plan were obvious to those guys.

My least favorite responsibility as Application Developer is the composition and maintenance of build files. Every once in awhile I’ll read a book that cites different roles within an organization – DBA, Backend Programmer, Frontend Programmer, GUI Designer, Assembler, Deployer, SysAdmin – and wonder why I’m doing all of them for one paycheck. I always wished there was some sucker down the hall with a business card that read “Assembly Engineer” to whom I could shove off all copy/compile/JAR tasks before going about my day.

Guess I’ve never been lucky enough to have that resource.

Here’s the problem: As simple as JBossAS is to get set up, once you start developing your application it’s likely that your server configuration will begin to sway from the default. It’s no longer an “unpack and run” situation, and this introduces a dangerous element; the environment used for local development might look very different from that used in primetime. Unless these changes are kept in check, it’s really easy to introduce bugs. Your application is not what you craft alone, but the sum total of all code churning at runtime. Everything needs to play nicely.

Easily fixed; with the introduction of an automated process, we can install and configure our server at the click of a button. This will keep our various environments in sync, with explicit differences we knowingly introduce.

I used to accomplish these goals using a series of Ant scripts, but anyone with experience in this arena knows how hellish making extensible Ant files can be. And forget cross-project portability. So this time around I’ll piggyback on Maven’s conventions.

Though close, CodeHaus’s jboss-maven-plugin didn’t quite hit the nail on the head for me. Architecturally, I needed some backing common libraries (unbound to the Maven Plugin API) such that I could mashup many of the components together for the new JBoss EJB3 Mavenized TestSuite. Not to mention that the SVN links are either outdated or the project is gonzo (Anyone? Bueller?), and I needed to add features.

Therefore, now under construction is the JBossAS Control Maven Plugin. This Blog entry is a Request for Comments.

Current Roadmap of Supported Goals Targeted for 1.0.0.GA:

install

Check for an installation at $JBOSS_HOME, and if not there, download and unpack a fresh version. May run in forced mode to always wipe the existing installation. Before I release this feature I’ll have to check with the appropriate channels about the legality of grabbing binaries from SourceForge, if there are some consent agreements or other useless red tape that have to be addressed.

create-config

From a specified base, create a new configuration. Customize by adding/overwriting/deleting as appropriate. This starts us off from a well-known default, applies the delta that makes our custom configuration, and exits. An added benefit is that we know our custom changes implicitly. KISS.

deploy

Grab the specified deployable unit(s) and deploy ‘em.

undeploy

Control-Z the deployment of specified artifacts.

start

Start a JBossAS configuration with appropriate JVM/Server arguments.

stop

What goes up, must come down.

Anything else I should be including? Or specific implementation requests for these features?

In the short term, I’ll update this entry with Anonymous SVN Access[1] and links to other instructions when they become available.

I think that should do it for this project’s scope. Also in the works right now is a functional sample project illustrating the proper configuration of these goals within the Maven Lifecycle. With one command you can get a fresh copy of the server, configure it, start it up, deploy your application, run integration tests, and bring the whole thing down before generating reports.

Good for continuous build. Good for ensuring your local development environments are sync’d up with the stuff you’re putting in Stage/Production.

[STAMP] My Application 1 [STAMP] My Application 2 [STAMP] MyApplication 3 …

Well-planned integration testing addresses the differences in your server environments.

[STAMP] My Application 4 …

Reproducible build plan at every level is an absolute necessity.

Until you come home drunk one night, and can’t find your house because they all look the damn same.

S,
ALR

Reference:
Continuous Integration, Martin Fowler, 2006

Edits:
[1] http://anonsvn.jboss.org/repos/maven/plugins/jboss/trunk/