proxy.yup();
}
}
Notice in Listing 6-38 that rather than creating an instance of NameMatchMethodPointcut, we
configure the pointcut details on the instance of NameMatchMethodPointcutAdvisor. In this way, the
NameMatchMethodPointcutAdvisor is acting as both the Advisor and the Pointcut.
You can find full details of the different convenient Advisor implementations by exploring the
JavaDoc for the org.springframework.aop.support package. There is no noticeable performance
difference between the two approaches, and aside from there being slightly less code in the second
approach, there is very little difference in the actual coding approach. We prefer to stick with the first
approach because we feel the intent is slightly clearer in the code. At the end of the day, the style you
choose comes down to personal preference.
Understanding Proxies
So far, we have taken only a cursory look at the proxies generated by ProxyFactory. We mentioned
that two types of proxy are available in Spring: JDK proxies created using the JDK Proxy class and
CGLIB-based proxies created using the CGLIB Enhancer class. You may be wondering exactly what the
difference between the two proxies is and why Spring needs two different types of proxy. In this section,
we take a detailed look at the differences between the proxies.
The core goal of a proxy is to intercept Method Invocations and, where necessary, execute chains
of advice that apply to a particular method. The management and invocation of advice is largely proxy
independent and is managed by the Spring AOP framework. However, the proxy is responsible for
intercepting calls to all methods and passing them as necessary to the AOP framework for the advice to
be applied.
In addition to this core functionality, the proxy must also support a set of additional features. It is
possible to configure the proxy to expose itself via the AopContext class (which is an abstract class) so
that you can retrieve the proxy and invoke advised methods on the proxy from the target object. The
proxy is responsible for ensuring that when this option is enabled via ProxyFactory.setExposeProxy(),
the proxy class is appropriately exposed. In addition to this, all proxy classes implement the Advised
interface by default, which allows for, among other things, the advice chain to be changed after the proxy
has been created. A proxy must also ensure that any methods that return this--that is, return the proxied
target--do in fact return the proxy and not the target.
As you can see, a typical proxy has quite a lot of work to perform, and all of this logic is implemented
in both the JDK and CGLIB proxies.
Using JDK Dynamic Proxies
JDK proxies are the most basic type of proxy available in Spring. Unlike the CGLIB proxy, the JDK proxy
can generate proxies only of interfaces, not classes. In this way, any object you want to proxy must
implement at least one interface. In general, it is good design to use interfaces for your classes, but it is
not always possible, especially when you are working with third-party or legacy code. In this case, you
must use the CGLIB proxy.
When you are using the JDK proxy, all method calls are intercepted by the JVM and routed to the
invoke() method of the proxy. This method then determines whether the method in question is advised
(by the rules defined by the pointcut), and if so, it invokes the advice chain and then the method itself
using reflection. In addition to this, the invoke() method performs all the logic discussed in the
previous section.
The JDK proxy makes no determination between methods that are advised and unadvised until it is
in the invoke() method. This means that for unadvised methods on the proxy, the invoke() method is
Search WWH :
