Skip to Content

In the EJB 3.0: Interceptors and Callbacks Made Easy – Part I of these two-part blog series I gave a basic introduction to EJB 3.0 interceptors and discussed their main features. Now, we’ll have a detailed look into the

InvocationContext

interface and see some examples of interceptors use cases.

The <code>InvocationContext</code> interface

The  method returns the map with contextual data that can be used to pass information between interceptors. If they are invoked as a result of the invocation on a web service endpoint, this map will be the JAX-WS

MessageContext

object that has been passed to JAX-WS handlers.

The

proceed

method causes the invocation of the next interceptor method in the chain, or, when called from the last AroundInvoke method, the business method. If

InvocationContext.proceed()

is not called, no subsequent interceptor methods or bean business method or lifecycle callback method will be invoked. The

proceed

method returns the result of the next method invoked or

null

if a method returns

void

.

Interceptors use cases

Now, that we’ve layed out the fundamentals of EJB interceptors, let’s have a look at some examples of how they can be used to serve typical tasks in enterprise applications.

Profiling

Interceptors provide the possibility to add profiling logic to applications, which can be easily reused, extended, and enabled or disabled. Below is the code of a simple profiling interceptor class:

In order to enable profiling for all EJBs in an application, for a single EJB, or only for a single business method, we need to apply this interceptor at the appropriate level. For example:

@Stateless

@Interceptors(ProfilingInterceptor.class)

public class EmployeeServicesBean implements EmployeeServices {

   

}

enables profiling for all methods of the EmployeeServices bean.

Printing the profiling information to the default system output is not very smart, though. You can possibly think of various ways to extend this profiling logic. For instance, the JPA EntityManager can be injected and used in the interceptor class to store the information in a relational database:

Logging/tracing

Interceptors can also be used to trace method invocations with input parameters and return values:

Code-based security

Another application of interceptors could be for the implementation of custom security permission checks. In the next example the interceptor delegates to a specially designed SecurityServices bean to carry out the checks for calling a business method.

Exception handling

Interceptor methods are allowed to abort business method invocation, to catch and suppress exceptions and retry an invocation, or to throw a different exception. The example below shows a simple bank account withdrawal validation interceptor:

Conclusion

Interceptors are reusable framework components (“a framework for frameworks”) that can be seamlessly plugged in and extended as necessary. They bring new power to the EJB specification, they are easy to use and fit very well in certain use cases.

References:

EJB 3.0: Interceptors and Callbacks Made Easy – Part I

Java EE Web Services Technologies

Extending EJB 3.0 With Interceptors

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Anonymous
    Hi Vladimir Pavlov,
    Nice blog, I feel reading Head First EJB book once and EJB spec once is a must.

    Regards,
    Vivek Nidhi.

    (0) 
    1. Vladimir Pavlov Post author
      Thanks for the positive feedback, Vivek!
      I guess, there are a lot of books, articles, tutorials, etc. on EJB out there – and also here on SDN. I personally would not judge which one is better or worse 🙂 However, reading the whole EJB spec as a book, if you just want to build EJB apps – and not an EJB container implementation, might be an overkill.

      BR,
      Vladimir

      (0) 

Leave a Reply