Monday, December 28, 2009

EJB 3.1 goes final

The EJB 3.1 and Java EE 6 specifications finally closed this month and are up for download. On a personal level, I'd like to say that EJB 3.1 has been the most productive I've been on a specification, thanks in no small way to the truly amazing group we had. For many of us it is a labor of love.

First a major thanks to Ken Saks. Ken, for a first-time spec lead you did an outstanding job and handled group input like a pro. It's difficult when in a position of authority to both have an opinion and collect the opinions of others. Where one sits in that continuum defines them as a spec lead, sets the tone for the group, and shapes the spec itself. You struck a balance that was just right. You started conversations with proposals that weren't too firm, yet were clear in the goal. As well you actively encouraged the most input from the group without letting conversations drag on too long with no clear conclusion. Hat's off to you, Ken.

As well the deepest appreciation to my fellow Expert Group members. There were many, but a special thanks to Reza Rahman, Evan Ireland, Soloman Barghouthi, Carlo de Wolf, Gavin King, Florent Benoit, Adam Bien, and Kim Wonseok. It was an absolute pleasure working with you guys over the last two years. The specification wouldn't have turned out nearly as well without you. It truly was a great group. Let me leave my professionalism aside for a moment and simply say, you all rock.

In reference to the specification itself there are areas to which I feel more personally attached. The EJBs in .wars functionalty and of course the Embedded EJB Container API the highest among them. If you like them, please let me know. They have been a labor of love for me for quite some time. I have high hopes for these in regards to the lightweight EJB front and hope that people find great use in them. The Embedded EJB Container API in particular I see as just the beginning and I'm excited to see what innovations we can bring in EJB.next once more vendors have had the chance to implement it.

Other areas I find particularly exciting are @Schedule, @Singleton and @Asynchronous. These were a challenge and took a considerable amount of the group's time. @Schedule for the challenge in creating an API that is expressive yet simple. @Singleton for the locking and startup ordering. @Asynchronous for the utter simplicity of it that it was hard to know when to stop. In all of the above, I hope we found that magical line that gives enough functionality without cutting us off from adding more bits in the future. Time will tell.

Of course thanks to all the people who provided feedback to the group directly or indirectly through their projects. I know I collected a good amount of spec feedback from the OpenEJB users as did other EG members from their users/customers. This perhaps the most valuable and least thanked group. So on behalf of myself and I'm sure all of the other EG members a whole hearted thanks. You have our deepest gratitude.

With that I raise a glass to EJB 3.1! I look forward to working with everyone again in EJB.next! Salud!

Monday, August 17, 2009

Pattern: InvocationContext Propagation

Another good name for this pattern might be ThreadLocal Encapsulation.

This pattern is a real ThreadLocal killer as it is a way to track state over several calls without widespread ThreadLocal usage.

Internally in OpenEJB we have managed to boil all our ThreadLocal usage down to this sort of "one to rule them all" approach. When attempting to describe it to a user I started using the javax.interceptor.InvocationContext as an example. The result was an ejb3 design pattern that is too cool not to share.

Add the following Interceptor as a global interceptor at the beginning of the interceptor stack.
The Interceptor uses a private ThreadLocal to propagate invocation state by linking the InvocationContext objects together. The result is that you can do an infinite amount of state tracking as well as write some pretty impressive diagnostic tools.

Anyone downstream of this interceptor can make a call like this to get access the an infinite amout of state up the stack. You can move specific state forward for quick access. You can also look infinitely back the invocation chain for state set in a previous InvocationContext. Or perhaps more elegantly as a recursive method. A JavaDoc'ed and ASL licensed version here: http://gist.github.com/168153