JavaOne Tuesday: Nuts and Bolts of Java EE 7 Interceptors

Interceptors 1.2 Specification

This session was held by Marina Vatkina and Emmanuel Bernard about JSR-318, the Interceptors 1.2 specification. Its basically a cleanup of the previous version with a few new features. Summary:

• Better, more organized, cleaner specification with better separation from other specs.
• Interceptor binding is now part of this specification (moved from CDI spec).
• No ejb-jar.xml elements in the specification (moved to EJB spec).
• New @AroundConstruct annotation to apply around object constructors. Note that this completes before injection happens!
• New @Priority annotation in EE 7 for ordering interceptors.

Influence of Bean Validation 1.1

Emmanuel Bernard went on explaining how the Bean Validation 1.1 features influenced the new Interceptors specification, namely:

• Return value and parameter (including constructor parameter) validation upon method calls. This was a strongly missing feature from BV 1.0. In this context the validation should really happen on method calls, not triggered by some clever framework or custom enforcement point, so there needs to be a way to do this. This is where interceptors come into the picture.
• Validations need to be executed as late as possible in the interceptor chain, so there needs to be some kind of ordering. @Priority is the solution for this.

Note: The BV 1.1 reference implementation uses a CDI portable extension to programmatically add interceptors based on the validation annotations, so it is fully standard and interoperable Java EE solution.

Interceptor Ordering

Important properties of the @Priority annotation:

• It is defined on the interceptor class, not on the intercepted class.
• Ordering is undefined for interceptors that have the same priority.
• EJB style interceptor declaration (@Interceptors) ignores this annotation as there would be no reasonable way to resolve priority conflicts.
• There are some useful predefined values in the Interceptor.Priority class like PLATFORM_BEFORE, LIBRARY_BEFORE, APPLICATION etc. Suggested best practice is to define your custom ranges between these values so that they have a meaning in this context.

So now the global ordering of all interceptors (including lifecycle callbacks and EJB style) is defined as follows:

1. interceptors bound using @Interceptors as ordered in the annotation
2. interceptors bound using @InterceptorBinding, ordered by their @Priority
3. interceptors on the target class (superclass first) (e.g. @PostConstruct)
4. interceptors on the target method or constructor

Others

Other slight modifications are that lifecycle callback method signatures can have return values and can throw checked exceptions now. This is just to avoid boilerplate try-catch code as InvocationContext.proceed() can throw checked exceptions. Note that this is only the signature, they are still not allowed to do so!

There is a new @Transactional annotation in EE 7 for JTA declarative transactions that can be applied to CDI managed beans, but not to EJBs (as it would conflict with JTA EJB interceptors). (Note that transactional interceptors have a mandated predefined @Priority. See the javadoc.)

That was it, it was nice to hear the new Interceptor and Bean Validation features. BTW did you know that in BV 1.1 you can inject resources into your constraint validators? That was missing before as well.

Cheers.

Update: Here is the link for the presentation's site and the slides.