Conditional Interception
Sometimes we want to restrict interception to some methods, or to some classes.
You can choose to use different interception stacks for different implementation classes, but that will mean having multiple ProxyInterceptor instances
in your application, and then choosing between them each time you want to place interceptors around an object. And that technique doesn't let you pick which methods
to intercept.
Your interceptors can have this logic built into them if you wish. The interceptor knows which object and method it is intercepting so it is possible to have different behaviours based on that information. Sometimes this may be the right approach, but in a lot of cases you will find it causes two issues:
- An interceptor that does nothing is a performance overhead, with no benefit
- Mixing the "what to do" and the "when to do it" into one class ties together two mostly unrelated concerns
You will see how to apply these rules in the next step.
The AnnotationPresentRule
The AnnotationPresentRule will perform interception when an annotation is
present. It detects annotations at the class level (on either the interface, or the implementation) and at the method level (also on the interface or implementation).
e.g. You might wish to perform certain security checks around methods marked with @AccessControl.
The InstanceOfRule
The InstanceOfRule will perform interception when the object to be intercepted
is an instance of a specified type. e.g. In the configuration_service sample code the
ConnectionAwareInterceptor should only be applied to objects that implement ConnectionAware.
Other rules
The javadoc for InterceptionRule lists all the different rules that are packaged with tie. (See the "All Known Implementing Classes" section at the top.)
Write your own rules
To write a rule, you simply need to create a class that implements InteceptionRule. The cook book provides
examples of this.
The instructions listed above require the "ext" jar to be on the classpath.