Default Interceptor

A default interceptor is invoked any time a business method of any bean within that deployment is invoked, unless default interceptors have been excluded on beans or business methods of beans.

To define a default interceptor for your deployment, model the standard <<Interceptor>> stereotype on a class and specify the andromda_service_interceptor_default tagged value as true on this class. Since this interceptor is invoked for all business methods of all beans, you do not need to model any dependencies on it. The cartridge will generate the class with the necessary interceptor operation and corresponding annotations within the interceptor class. It will also add the interceptor-binding attribute to the assembly-descriptor element of the ejb-jar deployment descriptor.

You can model as many default interceptor as you require, but at this stage, the ordering of default interceptors is not guaranteed.

Class Level Interceptor

Class level interceptors are invoked when business methods of the modeled class are invoked, unless class level interceptors have been excluded on business methods.

To define a class level interceptor, model the <<Interceptor>> stereotype on a class. You must model a dependency from a source bean to this target class level interceptor so that the cartridge knows to configure this interceptor at the class level in the ejb-jar deployment descriptor.

If you would like to define multiple class level interceptors, then to guarantee the ordering in which these interceptors are invoked, you must draw a dependency from the first interceptor to the second interceptor and so forth. This will chain the interceptors and allow the cartridge to configure them correctly in the ejb-jar deployment descriptor.

Method Level Interceptor

Method level interceptors are very much similar to class level interceptors, but they are bound to a specific business method within a bean. This means that they are only invoked when the modeled business methods of the bean are invoked.

To define a method level interceptor, model the <<Interceptor>> stereotype on a class. You must model a dependency from a bean method to this target method level interceptor so that the cartridge knows to configure this interceptor at the method level in the ejb-jar deployment descriptor.

Chaining method level interceptors is exactly the same process as for class level interceptors.

Interceptor Ordering

The following shows the ordering of default, class and method level interceptors.

• Default Interceptors - Invoked before all other interceptors
• Class Level Interceptors - Invoked in the chain after default interceptors and before method level interceptors.
• Method Level Interceptors - Invoked in the chain after all class level interceptors.

The above are the ordering for externally defined interceptors. If you define class interceptor methods within your bean, then these are the last interceptors to be invoked.

Interceptor Exclusions

The EJB3 cartridge allows you to exclude default interceptors for beans and bean methods. It also allows you to exclude class level interceptors for bean methods.

To exclude the default interceptors, model the andromda_service_interceptor_excludeDefault tagged value. If this is applied to a bean class, then the interceptor will be ignored for all methods of the bean class. If it is modeled on a business method of a bean, then invocation of that business method will NOT trigger invocation of the defined default interceptors.

To exclude class level interceptors, model the andromda_service_interceptor_excludeClass tagged value on business method of beans. This will prevent the container from invoking the defined class level interceptor when the associated bean method is invoked.

Interceptor Tips

In situations where you have an inheritance hierarchy, interceptor methods from the super class are always invoked first. The exception to this rule is the case where the interceptor has been overridden, regardless of whether the overriding method is defined as an interceptor.

Once the interceptors have been generated, they will never be overwritten. This way, you can add your implementation for the interceptor and call InvocationContext.proceed() to continue to call the next interceptor.

Similar to bean classes, interceptor classes enjoy the benefits of dependency injection in much the same way. You can inject resources using the @Resource annotation or an entity manager using the @PersistenceContext annotation.