David Blevins' Blog

@ApplicationException is evil... sort of

2010-07-16T14:18:00.000-07:00

Historically EJB has frowned on RuntimeExceptions. Throwing them results in your transaction getting rolled back and your bean instance being immediately destroyed. You're welcome to try your transaction again ... just as long as you weren't keeping your data in your @Stateful session bean, cause, you know, the container just destroyed that... hope you didn't need it to retry your commit.

In EJB 3.0 the @ApplicationException type was added so that beans could throw RuntimeExceptions and not have their beans destroyed and have the choice to rollback any transaction in progress. Great! Only... how do you really use this for built-in exception types? XML you say? Yuk!

<ejb-jar>
    <assembly-descriptor>
        <application-exception>java.lang.RuntimeExceptions</application-exception>
    </assembly-descriptor>
</ejb-jar>

And is the above even a good idea? Definitely not! With something like that you're just asking for trouble. The bad part is that it effectively shuts off transaction exception handling for all beans in the entire application. Currently, though, this is your only option.

The problem is it is hard to use this annotation responsibly. It's often too bold and too difficult to take the hard line that a specific exception type is always fine to throw. It is completely lacking in pragmatism. There is no ability for developers to make a more refined choice.

Bottom line, it should be possible to specify how you would like a RuntimeException handled for a specific bean or method. Imagine @ApplicationException where modified like so:

@java.lang.annotation.Target({TYPE, METHOD})
@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
public static @interface ApplicationException {
    Class value();

    boolean rollback() default false;
}

Now, we can do things a little more refined:

@LocalBean
public static class OrangeBean {

    @ApplicationException(RuntimeException.class)
    public void doSomething() {

    }

    public void doSomethingElse() {
        
    }
}

In the above, the OrangeBean doSomething method would be allowed to throw a RuntimeException without a transaction rollback or the bean instance being destroyed.

As well, the annotation could be placed on the class level. Say we have an @Stateful bean that wraps an EXTENDED PersistenceContext so that business logic could more easily be done elsewhere, perhaps by an @Stateless bean that uses Bean-Managed Transactions and wishes to batch process several transactions against the EXTENDED persistence context in a loop:

@Stateful
@ApplicationException(javax.persistence.PersistenceException.class)
@TransactionAttribute(MANDATORY)
public static class EntityManagerWrapper implements EntityManager {

    @PersistenceContext(type = EXTENDED)
    private EntityManager delegate;

    @Override
    public void persist(Object o) {
        delegate.persist(o);
    }

    @Override
    public  T merge(T t) {
        return delegate.merge(t);
    }

    @Override
    public void remove(Object o) {
        delegate.remove(o);
    }

    @Override
    public  T find(Class tClass, Object o) {
        return delegate.find(tClass, o);
    }

    //... and so on
}

The EntityManager API does not throw checked exceptions, only derivatives of javax.persistence.PersistenceException which is itself a RuntimeException. To wrap an EntityManager the bean also need the ability to throw javax.persistence.PersistenceException without causing its destruction and transaction rollback. In that vein, the bean is marked @TransactionAttribute(MANDATORY) so it isn't possible to use the bean without already having a transaction in progress, making it clear that transaction management is not it's responsibility.

In another example, say we would like to create a bean that wishes not be destroyed when a RuntimeException is thrown, but it would still like the transactions it starts (via @TransactionAttribute(REQUIRES_NEW)) to be rolled back should a RuntimeException occur.

@Stateful
@TransactionAttribute(REQUIRES_NEW)
@ApplicationException(value = RuntimeException.class, rollback = true)
public static class YellowBean {

    public void doSomething() {

    }

    public void doSomethingElse() {

    }
}

Naturally, to make this API work with more than one exception type per method or bean, we would of course need a new @ApplicationExceptions (note the plural) to group several @ApplicationException annotations -- for those that are not annotation-aware, you cannot use the same annotation twice on a type, method, field or any member.

@java.lang.annotation.Target({TYPE, METHOD})
@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
public static @interface ApplicationExceptions {
    ApplicationException[] value() default {};
}

With that it would be possible to do all of the above for a few different exception types:

@Stateful
public static class RedBean {

    @ApplicationExceptions({
        @ApplicationException(NumberFormatException.class),
        @ApplicationException(ArrayIndexOutOfBoundsException.class),
        @ApplicationException(value = RuntimeException.class, rollback = true)
    })
    public void doSomething() {

    }

    public void doSomethingElse() {

    }
}

In the above the NumberFormatException and ArrayIndexOutOfBoundsException are considered OK and will not cause instance destruction or transaction rollback, however the '@ApplicationException(value = RuntimeException.class, rollback = true)' acts as a default clause of sorts and says all other RuntimeExceptions do not cause instance destruction, but do cause transaction rollback.

Conclusion: Being able to be more specific with @ApplicationException would be a great improvement. I definitely plan to propose it in EJB.next. If you like the idea, please leave a comment as numbers do greatly increase the likelihood of it being added. Other ideas on how to achieve a similar result more then welcome!

EJB annotations and Stereotyping

2010-06-18T18:32:00.000-07:00

Certainly for the EJB-related annotations, I would love to see @Stateless, @Stateful, @Singleton and @MessageDriven be used for stereotyping as well as all the other class level annotations for transactions, security, locking, timeouts and scheduling.

Great security example:

 @RolesAllowed({"SuperUser", "AccountAdmin", "SystemAdmin"})
 @Stereotype
 @Target(METHOD)
 @Retention(RUNTIME)
 public @interface Admins {}

In one swoop all the security rolls become controlled in one spot and there's no need to go changing a million usages to modify the roll names.

Here's a couple great scheduling examples:

 @Schedule(second=”0”, minute=”0”, hour=”0”, month=”*”, dayOfWeek=”*”, year=”*”)
 @Stereotype
 @Target(METHOD)
 @Retention(RUNTIME)
 public @interface Daily {}

 @Schedule(second=”0”, minute=”0”, hour=”0”, month=”*”, dayOfMonth=”15,Last”, year=”*”)
 @Stereotype
 @Target(METHOD)
 @Retention(RUNTIME)
 public @interface BiMonthly {}

The list goes on and on. A much fuller example:

@Stereotype
@Singleton
@TransactionManagement(CONTAINER)
@TransactionAttribute(REQUIRED)
@ConcurrencyManagement(CONTAINER)
@Lock(READ)
@RolesAllowed({"SuperUser", "AccountAdmin", "SystemAdmin"})
@Interceptors({LoggingInterceptor.class, StatisticsInterceptor.class})
@Target(TYPE)
@Retention(RUNTIME)
public @interface SuperBean {}

And to use all that, just:

@SuperBean
public class MyBean {

    public void doSomething() {
        
    }
}

Annotation Scanning Standard

2010-06-18T15:46:00.000-07:00

We (the industry) need to get something in place for Java EE 7 to get scanning under control at a platform level. The metadata-complete concept of each individual spec is less helpful given the growing number of specifications that can have class-level "discoverable" annotations.

The rules we have for scanning for ejbs in a webapp are quite unintuitive. And how they relate to the scanning of the new Java EE 6 level annotations are unintuitive to the point that how they are handled, I bet, is rather vendor specific:

@DataSourceDefinition(s)

@ManagedBean

The cost of scanning a jar is constant in that it doesn't matter how many annotations you might be looking for or what spec they come from. If each individual spec continues to add spec-specific descriptor support for specifying which jars to scan, we're going to wind up with a rather big mess.

We should lock this down with a clean and simple file to control which jars.

Something as simple as the following would be a massive improvement.

META-INF/scanning.xml

<scanning>
  <jars>
    <jar>foo.jar</jar>
    <jar>bar.jar</jar>
  </jars>
  <packages>
    <package>org.foo.widgets</package>
    <package>com.bar.components</package>
  </packages>
</scanning>

I'd love it to have regex support, but even without it there's a big improvement.

If Software is pizza, EJB is the House Special

2010-06-12T18:06:00.000-07:00

If you can stand terrible food metaphors and have ever been exposed to EJB positively or negatively, keep reading....

I don't know about you, but I love the simplicity of a good pepperoni pizza now and then. Imagine asking for a plain Pepperoni pizza and being told your only option was to get the House Special and to pick off all the onions, black olives, green pepper and whatever else comes on top. Any person with options would simply go to another pizza shop. Well, that's EJB. Something I hope we can change in EJB 4.0.

To setup the metaphor a bit more, let's say the dough and cheese is the component itself and the proxy to the component. The toppings are the various QOSs (qualities of service) such as transaction management, interceptors, concurrency management, cron-like scheduling, asynchronous method calls, and other goodness. Each bean type such as Stateful, Stateless, Singleton and Message Driven are certain styles of pizza with a fixed set of toppings; say Meat Lovers, Vegetarian, or Hawaiian. The toppings of each style of pizza have been selected carefully to compliment each other perfectly and guarantee good results.

Currently though, if you want to start with a plain pizza and add only the toppings you want or need, you cannot do it with EJB. If you want pepperoni, you need to pick a style of pizza that has pepperoni as a topping and deal with the other toppings that come with it, wanted or not. EJB is somewhat flexible and there are usually ways to neutralize some features that amounts to picking off the toppings you don't like, but it's not the same as if they weren't ever there and you are still going to get an odd tasting and odd looking pizza.

Say you don't really want the transaction management topping. You try to pick off the topping by selecting SUPPORTS as your default transaction attribute so if a transaction is there, your bean participates in it, if not, it still does it's work regardless. All is fine until your bean throws a runtime exception and the container decides to rollback the current transaction on your behalf. Say you instead choose to try and pick off the transactional topping by making your bean use bean-managed transactions. Things work fine except now all transactions are suspended by the container so that the bean cannot mess with the state of what was the current transaction. What you really wanted was your bean to not be transactionally aware in the first place.

Unfortunately if you want one of the other toppings like container managed concurrency, cron-like scheduling, or asynchronous method calls, you have to learn to like the transaction management topping, period.

There will always be a need for specific pizza styles with pre-selected toppings -- who doesn't love a good Greek pizza or a Hawaiian now and then. The EJB spec does that well with its perfectly selected bean types, each sprinkled with the select set of QOSs deemed appropriate for that specific bean type. That said, it really should be possible to start with a plain cheese pizza and just add the toppings you want.

Forget the dough and cheese. EJB should be about the toppings.

Ideally, every QOS the EJB spec has to offer would be an option that can be applied to a plain component. Imagine if there was a "plain cheese pizza" bean type that would by default have no QOSs at all and for all intense purposes be a true POJO. There's nothing to learn or study to code it or use it. It's just a POJO created by the container. Then one day you decide you'd like it to be transaction aware. At that point you annotate it with @TransactionManagement and then go read the self contained "transaction management" section of the spec to see what is now expected of you and the users of the bean.

It may be that certain QOSs cannot be combined, which is in fact the case at times. The concept of a container managed persistence context (i.e. a field like "@PersistenceContext EntityManager myEntityManager") cannot be combined with the new @ConcurrencyManagement annotation because EntityManagers themselves are not guaranteed to be capable of concurrency. As a result EJB Singletons are not allowed to use container managed persistence contexts. That may work for some, but maybe you want a Singleton that uses a container managed persistence contexts and do not need concurrency anyway. Such a thing would be possible if you were able to choose the QOSs for your bean regardless of its lifecycle.

It's time to break up the big specs and let people build their own pizzas.

Man-page based Bash Completion

2010-03-02T15:01:00.001-08:00

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

2009-12-28T06:41:00.000-08:00

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

2009-08-17T13:54:00.000-07:00

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

2008-04-15T23:09:00.001-07:00

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

2008-04-12T21:59:00.000-07:00

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