Man-page based Bash Completion

Hacked up this little function which you can use to get generic bash completion on any command based on the man page. You just need to source this file. Here's what it looks like when executed

mingus:~ 03:16:45 
$ wget --c[TAB]
--ca-certificate=file      --certificate=file         --convert-links
--ca-directory=directory   --connect-timeout=seconds  --cut-dirs=number
--certificate-type=type    --continue                 

Theoretically you could take this a step further and complete the values of the options as well. Many of the options say "--foo=file", "--foo file", "--bar host", etc.. You could parse out this "file" or "host" keyword and switch the completion style accordingly. If you 'apt-get install bash-completion' you'll get a ton of completion functions which specialize in host, file, and directory completion. Shouldn't be too hard to wire them in. If anyone gets the urge to do it, definitely share your results. The above code is stored in gist.github.com, so fork away!

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!

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

OpenEJB Revival

After a year and a half of internal development and six months of betas, the 3.0 codebase has matured and solidified into the OpenEJB I've always dreamt of.

OpenEJB 3.0 achieves much of the original vision OpenEJB set out to accomplish eight years ago. With a Tomcat integration that allows Tomcat users to still enjoy the Tomcat they know and love yet take advantage of many Java EE features for both Servlets and EJBs and an ultra lightweight, embeddable EJB container for simple, plugin-free, unit testing that's impressively fast, remarkably easy to use and far more complete than any mock container out there, OpenEJB 3.0 offers a unique and powerful one-two punch that will be hard to beat.

OpenEJB has always gone in a different direction than the other EJB implementations, often to it's disadvantage. The idea of lightweight, embeddable and testable EJB was not something people were prepared to accept until recently. This left the project typically lacking in the resources required to keep up with the specs and took OpenEJB off the table for a good number of people. After the launch of EJB 3.0, however, people were finally ready to get on board with a lightweight and embeddable EJB implementation.

We launched our EJB 3.0 effort, OpenEJB 3.0, in early 2006 and went on a caffeine-charged coding bender for so long and so intensely that about half way in I had to give up drinking coffee completely. For me, it was very personal. Not just a fight for survival, but a fight two win. OpenEJB had always been a project of great promise, but seemed to never have all the right pieces at the right time. I had been working on the project for six years and it was time to go all in and win or go home. We achieved Java EE 5 certification as part of Geronimo in June 2007 and have been applying copious amounts of polish ever since. We're still the only open source EJB implementation to be included in a Java EE 5 certified platform aside from the RI itself.

The coming EJB 3.1 specification promises to be an even bigger boom. Several OpenEJB-born concepts are major focuses of EJB 3.1 specification such as the Collapsed EAR (ejbs and servlets side-by-side in the same archive and classloader) and embeddable EJB container for testing and Java SE environments. Similarly, the EJB 3.1 Lite profile describes OpenEJB to a tee and the EJB + Servlet profile maps directly to Tomcat with added OpenEJB.

If you're a Tomcat user, checkout OpenEJB 3.0. If you'd like an easy way to test your EJBs regardless of what platform you use, checkout OpenEJB 3.0; we natively support the full Glassfish descriptors, Geronimo of course, some of the WebLogic descriptors, and are happy to add more. If you've looked at OpenEJB in the past, especially OpenEJB 2.x, look again ... you'll be very surprised.

OpenEJB 3.0 Final Released

After a month of release candidates, fixing TCK issues, and other release polish... OpenEJB 3.0 is finally released! This release includes several improvements and refinements over the very successful 3.0 beta 2 release. Dependency injection has had a major boost with support for Java Generics and Enums. A dozen new validations makes it even harder to do something "wrong". JPA users will find it nearly impossible to misconfigure the jta-data-source and non-jta-data-source. More robust EJB references allow for circular and lazy references to ejbs in other ears. Deep levels of annotation inheritance are completely respected, allowing for greater design control and less duplicate code. Release notes: http://www.apache.org/dist/openejb/3.0/RELEASE-NOTES.txt Download: http://openejb.apache.org/openejb-30.html