Java Reference
In-Depth Information
Let's take a bird's-eye view of this code before analyzing each feature in detail in the
coming sections. The interceptor class,
ActionBazaarLogger
, is attached to the
ad-
dBid()
method of the
PlaceBidBean
stateless session bean using the
@Intercept-
ors
annotation . The
ActionBazaarLogger
object's
logMethodEntry()
method is annotated with
@AroundInvoke
. When the
addBid()
method is called,
the method call will be intercepted by
ActionBazaarLogger
and the
logMeth-
odEntry()
method will be invoked before the
addBid()
. The
logMethodEntry()
method prints a log message to the system console and uses
InvocationContext
to in-
clude the method name being entered. Finally, the
InvocationContext.proceed()
method is called to signal to the container that the
addBid()
invocation can proceed nor-
mally.
Interceptors can be implemented either in the bean class itself or in separate classes. We
recommend that you create interceptor methods external to the bean class because that ap-
proach allows you to separate crosscutting concerns from business logic and you can share
the methods among multiple beans. After all, isn't that the whole point of AOP?
Around-invoke methods
It's important to realize that an interceptor must always have only one method that's des-
ignated as the around-invoke (
@AroundInvoke
) method. Around-invoke methods must
not be business methods, which means that they shouldn't be public methods in the bean's
business interface(s).
An around-invoke method is automatically triggered by the container when a client invokes
a method that has designated it to be its interceptor. In
listing 5.10
, the triggered method is
marked with the
@AroundInvoke
annotation:
@AroundInvoke
public Object logMethodEntry(InvocationContext invocationContext)
throws Exception {
System.out.println("Entering method: "
+ invocationContext.getMethod().getName());
return invocationContext.proceed();
}
