Is TargetBean?: true
Is IsModified?: true
Has been modified?: false
Has been modified?: false
Has been modified?: true
As expected, both instanceof tests return true. Notice that the first call to isModified(), before any
modification occurred, returns false. The next call, after we set the value of name to the same value, also
returns false. For the final call, however, after we set the value of name to a new value, the isModified()
method returns true, indicating that the object has in fact been modified.
Introduction Summary
Introductions are one of the most powerful features of Spring AOP; they allow you not only to extend the
functionality of existing methods but also to extend the set of interfaces and object implements
dynamically. Using introductions is the perfect way to implement crosscutting logic that your application
interacts with through well-defined interfaces. In general, this is the kind of logic that you want to apply
declaratively rather than programmatically. By using the IsModifiedMixin defined in this example and the
framework services discussed in the next section, we can declaratively define which objects are capable of
modification checks, without needing to modify the implementations of those objects.
Obviously, because introductions work via proxies, they add a certain amount of overhead, and all
methods on the proxy are considered to be advised, because you cannot use pointcuts in conjunction
with introductions. However, in the case of many of the services that you can implement using
introductions such as the object modification check, this performance overhead is a small price to pay
for the reduction in code required to implement the service, as well the increase in stability and
maintainability that comes from fully centralizing the service logic.
Framework Services for AOP
Up to now, we have had to write a lot of code to advise objects and generate the proxies for them.
Although this in itself is not a huge problem, it does mean that all advice configuration is hard-coded
into your application, removing some of the benefits of being able to advise a method implementation
transparently. Thankfully, Spring provides additional framework services that allow you to create an
advised proxy in your application configuration and then inject this proxy into a target bean just like any
other dependencies.
Using the declarative approach to AOP configuration is preferable to the manual, programmatic
mechanism. When you use the declarative mechanism, not only do you externalize the configuration of
advice, but you also reduce the chance of coding errors. You can also take advantage of DI and AOP
combined to enable AOP so it can be used in a completely transparent environment.
Configuring AOP Declaratively
When using declarative configuration of Spring AOP, three options exist.
Using ProxyFactoryBean: In Spring AOP, the ProxyFactoryBean provides a
·
declarative way for configuring Spring's ApplicationContext (and hence the
underlying BeanFactory) in creating AOP proxies based on defined Spring beans.
Using Spring aop namespace: Introduced in Spring 2.0, the aop namespace
·
provides a simplified way (when compared to the ProxyFactoryBean) for defining
aspects and their DI requirements in Spring applications. However, the aop
namespace also uses the ProxyFactoryBean behind the scenes.
Search WWH :
