As a recap, table 5.9 contains a summary of both business method interceptors and lifecycle
Table 5.9. Differences between lifecycle and business method interceptors. Lifecycle interceptors are created
to handle EJB lifecycle callbacks. Business method interceptors are associated with business methods and are
automatically invoked when a user invokes the business method.
Lifecycle callback methods
Business method interceptor
Gets invoked when a certain lifecycle event
Gets invoked when a business method is
called by a client.
In a separate Interceptor class or in the bean
In the class or an interceptor class.
void <METHOD> (InvocationContext)—in
a separate interceptor class. void
<METHOD>()—in the bean class.
@PreDestroy, @PostConstruct, @PrePas-
May throw application or runtime exception.
May catch and swallow runtime exceptions.
No other business interceptor methods or the
business method itself are called if an ex-
ception is thrown before calling the proceed
May throw runtime exceptions but must not
throw checked exceptions. May catch and
swallow exceptions. No other lifecycle call-
back methods are called if an exception is
Share the same security and transaction con-
text within which the original business
method was invoked.
Transaction and security con-
Clearly, interceptors are extremely important to EJB. It's likely that the AOP features in fu-
ture releases of EJB will grow more and more robust. Interceptors certainly have the poten-
tial to evolve into a robust way of extending the EJB platform itself, with vendors offering
new out-of-the-box interceptor-based services.
5.3.7. Using interceptors effectively
To use interceptors effectively, you have to keep in mind what interceptors are used for. In-
terceptors are used to implement crosscutting concern logic before or after a business meth-
od is executed. To effectively use interceptors, keep their use limited to these crosscutting
concerns like auditing, metrics, logging, error handling, and so on. Although interceptors
have the ability to examine and even change a return value from an executed method, try
to avoid doing this. Changing a return value usually involves a business requirement and,
as such, belongs in the bean itself as part of the bean's business logic.