Home

 

Interceptors

The EJB 3.0 specification defines the ability to apply custom made interceptors to the business methods of both session and message driven beans. Interceptors take the form of methods annotated with the @AroundInvoke annotation (Example | 4-1).

Example 14-1 Applying an interceptor

@Stateless

public class MySessionBean implements MyBusinessInterface {

	@Interceptors(LoggerInterceptor.class)    

	public Customer getCustomer(String ssn) {

      ...

	}

    ......

}

public class LoggerInterceptor {

	@AroundInvoke

	public Object logMethodEntry(InvocationContext invocationContext)

																	throws Exception {

		System.out.println("Entering method: "

									+ invocationContext.getMethod().getName());

		Object result = invocationContext.proceed();

		// could have more logic here

		return result;

	}

}

We have the following notes for this example:

The @Interceptors annotation is used to identify the session bean method where the interceptor should be applied;

The LoggerInterceptor interceptor class defines a method (logMethodEntry) annotated with @AroundInvoke.

The logMethodEntry method contains the advisor logic (in this case it very simply logs the invoked method name), and invokes the proceed method on the InvocationContext interface to advise the container to proceed with the execution of the business method.

The implementation of interceptor in EJB 3.0 is a bit different from the analogous implementation of the aspect-oriented programming (AOP) paradigm that you can find in frameworks such as Spring or AspectJ, because EJB 3.0 does not support before or after advisors, but only around interceptors.

However, around interceptors can act as before or after interceptors, or both. Interceptor code before the invocationContext.proceed call is run before the EJB method, and interceptor code after that call is run after the EJB method.

A very common use of interceptors is to provide preliminary checks (validation, security, and so forth) before the invocation of business logic tasks, and therefore they can throw exceptions. Because the interceptor is called together with the session bean code at run-time, these potential exceptions are sent directly to the invoking client.

In this sample we have seen an interceptor applied on a specific method; actually, the @Interceptors annotation can be applied at class level. In this case the interceptor will be called for every method.

Furthermore, the @Interceptors annotation accepts a list of classes, so that multiple interceptors can be applied to the same object.

Note: To give further flexibility, EJB 3.0 introduces the concept of a default interceptor that can be applied on every session (or MDB) bean contained inside the same EJB module. A default interceptor cannot be specified using an annotation; instead, you should define it inside the deployment descriptor of the EJB module. Note that the execution order in which interceptors are run is as follows: Default interceptor Class interceptors Method interceptors

To disable the invocation of a default interceptor or a class interceptor on a specific method, you can use the @ExcludeDefaultInterceptors and @ExcludeClassInterceptors annotations, respectively.

ibm.com/redbooks