Spring的切入点模型使得切入点可以独立于通知（advice）类型进行重用，这就使得针对不同通知使用相同的pointcut成为可能。

org.springframework.aop.Pointcut是最核心的接口，用来将通知应用于特定的类和方法，完整的接口定义如下：

public interface Pointcut {

    ClassFilter getClassFilter();

    MethodMatcher getMethodMatcher();

        }

将Pointcut接口分割成有利于重用类和方法匹配的两部分， 以及进行更细粒度的操作组合（例如与另一个方法匹配实现进行“或操作”）。

ClassFilter接口用来将切入点限定在一个给定的类集合中。 如果matches()方法总是返回true，所有目标类都将被匹配：

public interface ClassFilter {

    boolean matches(Class clazz);
        }

MethodMatcher接口通常更重要，完整的接口定义如下：

public interface MethodMatcher {

    boolean matches(Method m, Class targetClass);

    boolean isRuntime();

    boolean matches(Method m, Class targetClass, Object[] args);
        }

matches(Method, Class)方法用来测试这个切入点是否匹配目标类的指定方法。 这将在AOP代理被创建的时候进行运算，这样可以避免在每次方法调用的时候都运算。 如果matches(Method, Class)对于一个给定的方法返回true，并且isRuntime()也返回true， 那么matches(Method, Class, Object[])将在每个方法调用的时候被调用。 这使得切入点在通知将被执行前可以查看传入到方法的参数。

大多数MethodMatcher是静态的，这意味着isRuntime()方法返回false。 在这种情况下，matches(Method, Class , Object[])永远不会被调用。

	Tip
	应尽可能地使切入点保持静态，这就允许AOP框架在AOP代理被创建时缓存对切入点的计算结果。

Spring在切入点上支持以下运算： 或和与。

从2.0开始，Spring中使用的最重要的切入点类型是org.springframework.aop.aspectj.AspectJExpressionPointcut。 这个切入点使用AspectJ提供的库来解析满足AspectJ语法切入点表达式字符串。

可以查看前一章关于所支持的AspectJ切入点原语的讨论。

Spring提供了一些很方便的切入点实现。一些可直接使用，其它的则是切入点应用规范的子集。

<bean id="settersAndAbsquatulatePointcut" 
                        class="org.springframework.aop.support.Perl5RegexpMethodPointcut">
                        <property name="patterns">
                        <list>
                        <value>.*set.*</value>
                        <value>.*absquatulate</value>
                        </list>
                        </property>
                    </bean>

<bean id="settersAndAbsquatulateAdvisor" 
                        class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
                        <property name="advice">
                        <ref local="beanNameOfAopAllianceInterceptor"/>
                        </property>
                        <property name="patterns">
                        <list>
                        <value>.*set.*</value>
                        <value>.*absquatulate</value>
                        </list>
                        </property>
                    </bean>

7.2.4.2. 动态切入点

动态切入点比起静态切入点在执行时要消耗更多的资源。它们同时计算方法参数和静态信息。 这意味着它们必须在每次方法调用时都被计算；由于参数的不同，结果不能被缓存。

动态切入点的主要例子是控制流切入点。

7.2.4.2.1. 控制流切入点

Spring控制流切入点在概念上和AspectJ的cflow 切入点很相似， 虽然它的功能不如后者那么强大。（目前还不能让一个切入点在另外一个切入点所匹配的连接点处执行）。 一个控制流切入点匹配当前的调用栈。例如，一个连接点被com.mycompany.web 包内的一个方法或者SomeCaller类调用，切入点就可能被激活。 控制流切入点是由org.springframework.aop.support.ControlFlowPointcut类声明的。

	Note
	在运行时控制流切入点的开销是非常昂贵的，甚至与其它动态切入点比起来也是如此。在Java 1.4里， 它的开销差不多是其它动态切入点的5倍。

Spring提供了很多有用的切入点超类来帮助你实现你自己的切入点。

因为静态切入点是最常用的，你可能会像下面那样继承StaticMethodMatcherPointcut。这只需要实现一个抽象方法 （虽然也可以覆盖其它方法来定制行为）：

class TestStaticPointcut extends StaticMethodMatcherPointcut {
                
                public boolean matches(Method m, Class targetClass) {
                // return true if custom criteria match
                }
        }

动态切入点也有很多超类。

你可以在使用自定义切入点的同时结合Spring 1.0 RC2和更高版本中的任意通知类型。

因为在Spring AOP中的切入点是Java类而不是语言的特性（就像AspectJ那样），所以可以声明自定义的切入点，不论是静态还是动态的。 自定义切入点在Spring里可能很强大。即使这样我们仍推荐尽可能使用AspectJ切入点表达式语言。

	Note
	后续版本的Spring也许会提供“语义切入点”，像JAC所提供的那样：例如，“所有方法可以修改目标对象中实例变量”

每个通知都是一个Spring bean。一个通知实例既可以被所有被通知的对象共享，也可以被每个被通知对象独占。 这根据设置类共享（per-class）或基于实例（per-instance）的参数来决定。

类共享通知经常会被用到。它很适合用作通用的通知例如事务通知器（advisor）。这些通知器不依赖于代理对象的状态也不会向代理对象添加新的状态； 它们仅仅在方法和参数上起作用。

基于实例的通知很适合用作导入器来支持混合类型（mixin）。在这种情况下，通知向代理对象添加状态。

在同一个AOP代理里混合使用类共享和基于实例的通知是可能的。

Spring自带了多种通知类型，而且它们也可以被扩展来支持各种通知类型。让我们先看看基本概念和标准的通知类型。

7.3.2.1. 拦截环绕通知

在Spring中最基础的通知类型是拦截环绕通知（interception around advice）。

Spring里使用方法拦截的环绕通知兼容AOP联盟接口。实现环绕通知的MethodInterceptor应当实现下面的接口：

public interface MethodInterceptor extends Interceptor {
                
                Object invoke(MethodInvocation invocation) throws Throwable;
            }

invoke()方法的MethodInvocation参数暴露了被调用的方法； 目标连接点；AOP代理以及传递给方法的参数。invoke()方法应该返回调用的结果：即连接点的返回值。

一个简单的MethodInterceptor实现看起来像下面这样：

public class DebugInterceptor implements MethodInterceptor {
                
                public Object invoke(MethodInvocation invocation) throws Throwable {
                System.out.println("Before: invocation=[" + invocation + "]");
                Object rval = invocation.proceed();
                System.out.println("Invocation returned");
                return rval;
                }
            }

注意对MethodInvocation中proceed()方法的调用。 这个方法继续运行指向连接点的拦截器链并返回proceed()的结果。大多数拦截器会调用这个方法，返回一个值。 然而，一个类似任意环绕通知的MethodInterceptor，可以返回一个不同的值或者抛出一个异常而不是调用proceed方法。 但除非你有很好的理由，否则不要考虑这样做！

	Note
	MethodInterceptor提供了与其它AOP联盟兼容实现的互操作性。本节的剩下部分将讨论其它的通知类型， 它们实现了通用的AOP概念，但是以一种Spring风格的方式来实现的。使用最通用的通知类型还有一个好处， 固定使用MethodInterceptor环绕通知可以让你在其它的AOP框架里运行你所定制的切面。 要注意现在切入点还不能和其它框架进行互操作，AOP联盟目前还没有定义切入点接口。

7.3.2.2. 前置通知

一个更简单的通知类型是前置通知（before advice）。 它不需要MethodInvocation对象，因为它只是在进入方法之前被调用。

前置通知的一个主要优点是它不需要调用proceed()方法， 因此就不会发生无意间运行拦截器链失败的情况。

下面是MethodBeforeAdvice 接口。 （Spring的API设计能够为类中的成员变量提供前置通知，虽然通常对象会被应用于成员变量拦截之上，但看起来Spring并不打算实现这个功能。）

public interface MethodBeforeAdvice extends BeforeAdvice {
                
                void before(Method m, Object[] args, Object target) throws Throwable;
            }

注意返回值的类型是void。前置通知可以在连接点执行之前插入自定义行为，但是不能修改连接点的返回值。 如果一个前置通知抛出异常，这将中止拦截器链的进一步执行。异常将沿着拦截器链向回传播。 如果异常是非强制检查的（unchecked）或者已经被包含在被调用方法的throws声明中，它将被直接返回给客户端； 否则它将由AOP代理包装在一个非强制检查异常中返回。

这是一个Spring前置通知的例子，它计算所有方法被调用的次数：

public class CountingBeforeAdvice implements MethodBeforeAdvice {
                
                private int count;
                
                public void before(Method m, Object[] args, Object target) throws Throwable {
                ++count;
                }
                
                public int getCount() { 
                return count; 
                }
            }

	Tip
	前置通知可以和任何切入点一起使用。

7.3.2.3. 异常通知

如果连接点抛出异常，异常通知（throws advice）将在连接点返回后被调用。 Spring提供类型检查的异常通知（typed throws advice），这意味着org.springframework.aop.ThrowsAdvice接口不包含任何方法： 它只是一个标记接口用来标识所给对象实现了一个或者多个针对特定类型的异常通知方法。这些方法应当满足下面的格式:

afterThrowing([Method, args, target], subclassOfThrowable) 

只有最后一个参数是必须的。根据异常通知方法对方法及参数的需求，方法的签名可以有一个或者四个参数。 下面是一些异常通知的例子。

当一个RemoteException（包括它的子类）被抛出时，下面的通知会被调用：

public class RemoteThrowsAdvice implements ThrowsAdvice {

    public void afterThrowing(RemoteException ex) throws Throwable {
                // Do something with remote exception
    }
            }

当一个ServletException被抛出，下面的通知将被调用。 和上面的通知不同，它声明了4个参数，因此它可以访问被调用的方法，方法的参数以及目标对象：

public class ServletThrowsAdviceWithArguments implements ThrowsAdvice {

    public void afterThrowing(Method m, Object[] args, Object target, ServletException ex) {
                // Do something with all arguments
    }
            }

最后一个例子说明怎样在同一个类里使用两个方法来处理 RemoteException和ServletException。可以在一个类里组合任意数量的异常通知方法。

public static class CombinedThrowsAdvice implements ThrowsAdvice {
                
                public void afterThrowing(RemoteException ex) throws Throwable {
                // Do something with remote exception
                }
                
                public void afterThrowing(Method m, Object[] args, Object target, ServletException ex) {
                // Do something with all arguments
                }
            }

	Tip
	异常通知可以和任何切入点一起使用。

7.3.2.4. 后置通知

Spring中的后置通知（After Returning advice）必须实现 org.springframework.aop.AfterReturningAdvice 接口，像下面显示的那样：

public interface AfterReturningAdvice extends Advice {
                
                void afterReturning(Object returnValue, Method m, Object[] args, Object target) 
                throws Throwable;
            }

后置通知可以访问返回值（但不能进行修改），被调用方法，方法参数以及目标对象。

下面的后置通知计算所有运行成功（没有抛出异常）的方法调用：

public class CountingAfterReturningAdvice implements AfterReturningAdvice {
                
                private int count;
                
                public void afterReturning(Object returnValue, Method m, Object[] args, Object target)
                throws Throwable {
                ++count;
                }
                
                public int getCount() {
                return count;
                }
            }

这个通知不改变执行路径。如果抛出异常，它将沿着拦截器链被抛出而不是返回被调用方法的执行结果。

	Tip
	后置通知可以和任何切入点一起使用。

public interface IntroductionInterceptor extends MethodInterceptor {
                
                boolean implementsInterface(Class intf);
            }

public interface IntroductionAdvisor extends Advisor, IntroductionInfo {
                
                ClassFilter getClassFilter();
                
                void validateInterfaces() throws IllegalArgumentException;
                }
                
                public interface IntroductionInfo {
                
                Class[] getInterfaces();
            }

public interface Lockable {
                    void lock();
                    void unlock();
                    boolean locked();
                }

public class LockMixin extends DelegatingIntroductionInterceptor 
                    implements Lockable {
                    
                    private boolean locked;
                    
                    public void lock() {
                    this.locked = true;
                    }
                    
                    public void unlock() {
                    this.locked = false;
                    }
                    
                    public boolean locked() {
                    return this.locked;
                    }
                    
                    public Object invoke(MethodInvocation invocation) throws Throwable {
                    if (locked() && invocation.getMethod().getName().indexOf("set") == 0)
                    throw new LockedException();
                    return super.invoke(invocation);
                    }
                    
                }

public class LockMixinAdvisor extends DefaultIntroductionAdvisor {
                    
                    public LockMixinAdvisor() {
                    super(new LockMixin(), Lockable.class);
                    }
                }

像其它的FactoryBean实现一样，ProxyFactoryBean引入了一个间接层。如果你定义一个名为foo的ProxyFactoryBean， 引用foo的对象看到的将不是ProxyFactoryBean实例本身，而是一个ProxyFactoryBean实现里getObject() 方法所创建的对象。 这个方法将创建一个AOP代理，它包装了一个目标对象。

使用ProxyFactoryBean或者其它IoC相关类带来的最重要的好处之一就是创建AOP代理，这意味着通知和切入点也可以由IoC来管理。这是一个强大的功能并使得某些特定的解决方案成为可能， 而这些用其它AOP框架很难做到。例如，一个通知也许本身也要引用应用程序对象（不仅仅是其它AOP框架中也可以访问的目标对象），这令你可以从依赖注射的可拔插特性中获益。

通常情况下Spring提供了大多数的FactoryBean实现，ProxyFactoryBean类本身也是一个JavaBean。它的属性被用来：

一些主要属性从org.springframework.aop.framework.ProxyConfig里继承下来（这个类是Spring里所有AOP代理工厂的父类）。这些主要属性包括：

ProxyFactoryBean中需要说明的其它属性包括：

这个小节作为说明性文档，解释了对于一个目标对象（需要被代理的对象），ProxyFactryBean是如何决定究竟创建一个基于JDK还是CGLIB的代理的。

	Note
	ProxyFactoryBean需要创建基于JDK还是CGLIB代理的具体行为在版本1.2.x和2.0中有所不同。 现在ProxyFactoryBean在关于自动检测接口方面使用了与TransactionProxyFactoryBean相似的语义。

如果一个需要被代理的目标对象的类（后面将简单地称它为目标类）没有实现任何接口，那么一个基于CGLIB的代理将被创建。 这是最简单的场景，因为JDK代理是基于接口的，没有接口意味着没有使用JDK进行代理的可能。 在目标bean里将被插入探测代码，通过interceptorNames属性给出了拦截器的列表。 注意一个基于CGLIB的代理将被创建即使ProxyFactoryBean的proxyTargetClass属性被设置为false。 （很明显这种情况下对这个属性进行设置是没有意义的，最好把它从bean的定义中移除，因为虽然这只是个多余的属性，但在许多情况下会引起混淆。）

如果目标类实现了一个（或者更多）接口，那么创建代理的类型将根据ProxyFactoryBean的配置来决定。

如果ProxyFactoryBean的proxyTargetClass属性被设为true，那么一个基于CGLIB的代理将创建。 这样的规定是有意义的，遵循了最小惊讶法则（保证了设定的一致性）。甚至当ProxyFactoryBean的proxyInterfaces属性被设置为一个或者多个全限定接口名， 而proxyTargetClass属性被设置为true仍然将实际使用基于CGLIB的代理。

如果ProxyFactoryBean的proxyInterfaces属性被设置为一个或者多个全限定接口名，一个基于JDK的代理将被创建。 被创建的代理将实现所有在proxyInterfaces属性里被说明的接口； 如果目标类实现了全部在proxyInterfaces属性里说明的接口以及一些额外接口，返回的代理将只实现说明的接口而不会实现那些额外接口。

如果ProxyFactoryBean的proxyInterfaces属性没有被设置， 但是目标类实现了一个（或者更多）接口，那么ProxyFactoryBean将自动检测到这个目标类已经实现了至少一个接口， 一个基于JDK的代理将被创建。被实际代理的接口将是目标类所实现的全部接口； 实际上，这和在proxyInterfaces属性中列出目标类实现的每个接口的情况是一样的。 然而，这将显著地减少工作量以及输入错误的可能性。

让我们看一个关于ProxyFactoryBean的简单例子。这个例子涉及：

<bean id="personTarget" class="com.mycompany.PersonImpl">
                <property name="name"><value>Tony</value></property>
                <property name="age"><value>51</value></property>
                </bean>
                
                <bean id="myAdvisor" class="com.mycompany.MyAdvisor">
                <property name="someProperty"><value>Custom string property value</value></property>
                </bean>
                
                <bean id="debugInterceptor" class="org.springframework.aop.interceptor.DebugInterceptor">
                </bean>
                
                <bean id="person" 
                class="org.springframework.aop.framework.ProxyFactoryBean">
                <property name="proxyInterfaces"><value>com.mycompany.Person</value></property>
                
                <property name="target"><ref local="personTarget"/></property>
                <property name="interceptorNames">
                <list>
                <value>myAdvisor</value>
                <value>debugInterceptor</value>
                </list>
                </property>
            </bean>

注意interceptorNames属性接受一组字符串：当前工厂中拦截器或通知器bean的名字。 拦截器，通知器，前置, 后置和异常通知对象都可以在这里被使用。这里通知器的顺序是很重要的。

	Note
	你也许很奇怪为什么这个列表不保存bean的引用。理由是如果ProxyFactoryBean的singleton属性被设置为false，它必须返回独立的代理实例。 如果任何通知器本身是一个原型，则每次都返回一个独立实例，因此它必须能够从工厂里获得原型的一个实例；保存一个引用是不够的。

上面“person” bean的定义可以被用来取代一个Person接口的实现，就像下面这样：

Person person = (Person) factory.getBean("person");

在同一个IoC上下文中其它的bean可以对这个bean有基于类型的依赖，就像对一个普通的Java对象那样：

<bean id="personUser" class="com.mycompany.PersonUser">
                <property name="person"><ref local="person" /></property>
            </bean>

这个例子里的PersonUser类将暴露一个类型为Person的属性。就像我们关心的那样，AOP代理可以透明地取代一个“真实”的person接口实现。 然而，它的类将是一个动态代理类。 它可以被转型成Advised接口（将在下面讨论）。

就像下面这样，你可以使用一个匿名内部bean来隐藏目标和代理之间的区别。 仅仅ProxyFactoryBean的定义有所不同；通知的定义只是由于完整性的原因而被包括进来：

<bean id="myAdvisor" class="com.mycompany.MyAdvisor">
                <property name="someProperty"><value>Custom string property value</value></property>
                </bean>
                
                <bean id="debugInterceptor" class="org.springframework.aop.interceptor.DebugInterceptor"/>
                
                <bean id="person" class="org.springframework.aop.framework.ProxyFactoryBean">
                <property name="proxyInterfaces"><value>com.mycompany.Person</value></property>
                <!-- Use inner bean, not local reference to target -->
                <property name="target">
                <bean class="com.mycompany.PersonImpl">
                <property name="name"><value>Tony</value></property>
                <property name="age"><value>51</value></property>
                </bean>
                </property>
                <property name="interceptorNames">
                <list>
                <value>myAdvisor</value>
                <value>debugInterceptor</value>
                </list>
                </property>
            </bean>

对于只需要一个Person类型对象的情况，这是有好处的：如果你希望阻止应用程序上下文的用户获取一个指向未通知对象的引用或者希望避免使用Spring IoC 自动织入 时的混淆。 按理说ProxyFactoryBean定义还有一个优点是它是自包含的。然而，有时能够从工厂里获取未通知的目标也是一个优点：例如，在某些测试场景里。

如果你需要代理一个类而不是代理一个或是更多接口，那么情况将是怎样？

想象在我们上面的例子里，不存在Person接口：我们需要通知一个叫做Person的类，它没有实现任何业务接口。 在这种情况下，你可以配置Spring使用CGLIB代理，而不是动态代理。这只需简单地把上面ProxyFactoryBean的proxyTargetClass属性设为true。 虽然最佳方案是面向接口编程而不是类，但在与遗留代码一起工作时，通知没有实现接口的类的能力是非常有用的。 （通常情况下，Spring没有任何规定。它只是让你很容易根据实际情况选择最好的解决方案，避免强迫使用特定方式）。

也许你希望你能够在任何情况下都强制使用CGLIB，甚至在你使用接口的时候也这样做。

CGLIB通过在运行时生成一个目标类的子类来进行代理工作。 Spring配置这个生成的子类对原始目标对象的方法调用进行托管：子类实现了装饰器（Decorator）模式，把通知织入。

CGLIB的代理活动应当对用户是透明的。然而，有一些问题需要被考虑：

在CGLIB代理和动态代理之间的速度差别是很小的。在Spring 1.0中，动态代理会快一点点。但这点可能在将来被改变。 这种情况下，选择使用何种代理时速度不应该成为决定性的理由。

通过在一个拦截器名后添加一个星号，所有bean名字与星号之前部分相匹配的通知都将被加入到通知器链中。这让你很容易添加一组标准的“全局”通知器：

                <bean id="proxy" class="org.springframework.aop.framework.ProxyFactoryBean">
                <property name="target" ref="service"/>
                <property name="interceptorNames">
                <list>
                <value>globa *</value>
                </list>
                </property>
                </bean>
                
                <bean id="global_debug" class="org.springframework.aop.interceptor.DebugInterceptor"/>
                <bean id="global_performance" class="org.springframework.aop.interceptor.PerformanceMonitorInterceptor"/>
        

org.springframework.aop.framework.autoproxy包提供了下列标准自动代理创建器。

<bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
                    <property name="beanNames"><value>jdk*,onlyJdk</value></property>
                    <property name="interceptorNames">
                    <list>
                    <value>myInterceptor</value>
                    </list>
                    </property>
                </bean>

<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>
                    
                    <bean class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
                    <property name="transactionInterceptor" ref="transactionInterceptor"/>
                    </bean>
                    
                    <bean id="customAdvisor" class="com.mycompany.MyAdvisor"/>
                    
                    <bean id="businessObject1" class="com.mycompany.BusinessObject1">
                    <!-- Properties omitted -->
                    </bean>
                    
                    <bean id="businessObject2" class="com.mycompany.BusinessObject2"/>
                

一个非常重要的自动代理类型是由元数据驱动的。这提供了一种和.NET ServicedComponents相似的编程模型。 作为使用类似EJB里的XML描述符的替代，对于事务管理和其它企业服务的配置都将被保存在源代码级别的属性里。

在这个情况下，你使用DefaultAdvisorAutoProxyCreator和可以理解元数据属性的通知器。 元数据被保存在候选通知器的切入点部分中，而不是在自动代理创建类本身。

这是一个DefaultAdvisorAutoProxyCreator的特殊例子，它本身没有什么特别。（元数据的相关代码保存在通知器的切入点里，而不是AOP框架里）。

JPetStore示例应用程序的/attributes 目录显示了如何使用参数驱动的自动代理。在这个例子里，不需要使用TransactionProxyFactoryBean。因为使用了元数据相关的切入点， 所以简单在业务对象上定义事务属性就足够了。在/WEB-INF/declarativeServices.xml里的bean定义包括了下面的片断，注意这是通用的，可以被用在JPetStore以外的地方：

<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>
                
                <bean class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
                <property name="transactionInterceptor" ref="transactionInterceptor"/>
                </bean>
                
                <bean id="transactionInterceptor"
                class="org.springframework.transaction.interceptor.TransactionInterceptor">
                <property name="transactionManager" ref="transactionManager"/>
                <property name="transactionAttributeSource">
                <bean class="org.springframework.transaction.interceptor.AttributesTransactionAttributeSource">
                <property name="attributes" ref="attributes"/>
                </bean>
                </property>
                </bean>
                
            <bean id="attributes" class="org.springframework.metadata.commons.CommonsAttributes"/>

DefaultAdvisorAutoProxyCreator bean定义（名字是不重要的，因此甚至可以在定义里省略它）将在当前应用程序上下文中查找所有合适的切入点。在这个例子里，TransactionAttributeSourceAdvisor类型的“transactionAdvisor”bean定义将应用到带有一个事务属性的类或方法上。 TransactionAttributeSourceAdvisor的构造器依赖于一个TransactionInterceptor。这个例子里通过自动织入解决了这个问题。AttributesTransactionAttributeSource依赖于一个org.springframework.metadata.Attributes接口的实现。 在这个代码片断里，“attributes”bean使用Jakarta Commons Attributes API来获取属性信息以满足这个要求。（应用程序代码必须已经使用Commons Attribut来es的编译任务编译过了。）

JPetStore示例应用程序的 /annotation 目录包括了一个由JDK 1.5+注解驱动的自动代理的模拟例子。 下面的配置允许自动检测Spring的Transactional注解，这可以为包含注解的bean提供隐式代理：

<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>
                
                <bean class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
                <property name="transactionInterceptor" ref="transactionInterceptor"/>
                </bean>
                
                <bean id="transactionInterceptor"
                class="org.springframework.transaction.interceptor.TransactionInterceptor">
                <property name="transactionManager" ref="transactionManager"/>
                <property name="transactionAttributeSource">
                <bean class="org.springframework.transaction.annotation.AnnotationTransactionAttributeSource"/>
                </property>
            </bean>

这里定义的TransactionInterceptor依赖于一个PlatformTransactionManager定义， 后者没有被包括在这个通用的文件里（虽然它可以被包括在这里）因为它在应用程序的事务需求规范中指定（在这个例子里使用JTA，而在其它情况下，可以是Hibernate，JDO或者JDBC）：

<bean id="transactionManager" 
        class="org.springframework.transaction.jta.JtaTransactionManager"/>

	Tip
	如果你只需要声明式事务管理，使用这些通用的XML定义将导致Spring自动代理所有带有事务属性的类或者方法。你将不需要直接使用AOP工作， 这个编程模型和.NET的ServicedComponents相似。

这个架构是可以扩展的。可以在自定义属性的基础上进行自动代理。你所需要做的是：

可以让这些通知器对于每个被通知对象（例如，mixins）都是唯一的：仅仅需要在bean定义中被定义为原型而不是单例。 例如，在上面所显示的Spring测试集中的LockMixin引入拦截器可以和一个属性驱动的切入点联合定位一个mixin， 像这里显示的这样。我们使用通用的DefaultPointcutAdvisor，使用JavaBean属性进行配置：

<bean id="lockMixin" class="org.springframework.aop.LockMixin"
                scope="prototype"/>
                
                <bean id="lockableAdvisor" class="org.springframework.aop.support.DefaultPointcutAdvisor"
                scope="prototype">
                <property name="pointcut" ref="myAttributeAwarePointcut"/>
                <property name="advice" ref="lockMixin"/>
                </bean>
                
            <bean id="anyBean" class="anyclass" ...

如果参数相关的切入点匹配anyBean或其它bean定义里的任何方法，mixin将被应用。 注意lockMixin和lockableAdvisor的定义都是原型。 myAttributeAwarePointcut切入点可以是个单例，因为它没有为单个被通知对象保持状态。

org.springframework.aop.target.HotSwappableTargetSource允许当调用者保持引用的时候，切换一个AOP代理的目标。

修改目标源的目标将立即生效。 HotSwappableTargetSource是线程安全的。

你可以通过HotSwappableTargetSource的 swap()方法来改变目标，就像下面那样：

HotSwappableTargetSource swapper = 
                (HotSwappableTargetSource) beanFactory.getBean("swapper");
            Object oldTarget = swapper.swap(newTarget);

所需的XML定义看起来像下面这样：

<bean id="initialTarget" class="mycompany.OldTarget"/>
                
                <bean id="swapper" class="org.springframework.aop.target.HotSwappableTargetSource">
                <constructor-arg ref="initialTarget"/>
                </bean>
                
                <bean id="swappable" class="org.springframework.aop.framework.ProxyFactoryBean">
                <property name="targetSource" ref="swapper"/>
            </bean>

上面的swap()调用修改了swappable bean的目标。保持对这个bean的引用的客户将不知道发生了这个修改，但是将可以立即点击新的目标。

这个例子没有添加任何通知--也不必为使用一个TargetSource添加任何通知--当然任何TargetSource都可以与任意通知联合使用。

使用一个池化目标源提供了和无状态session EJB类似的编程模型，它维护一个包括相同实例的池，方法调用结束后将把对象释放回池中。

Spring池化和SLSB池化之间的一个决定性区别是Spring池化功能可以用于任何POJO。就像Spring通常情况下那样，这个服务是非侵入式的。

Spring对Jakarta Commons Pool 1.3提供了开箱即用的支持，后者提供了一个相当有效的池化实现。要使用这个特性，你需要在应用程序路径中存在commons-pool的Jar文件。 也可以通过继承org.springframework.aop.target.AbstractPoolingTargetSource来支持其它的池化API。

下面是示例配置：

<bean id="businessObjectTarget" class="com.mycompany.MyBusinessObject" 
                scope="prototype">
                ... properties omitted
                </bean>
                
                <bean id="poolTargetSource" class="org.springframework.aop.target.CommonsPoolTargetSource">
                <property name="targetBeanName" value="businessObjectTarget"/>
                <property name="maxSize" value="25"/>
                </bean>
                
                <bean id="businessObject" class="org.springframework.aop.framework.ProxyFactoryBean">
                <property name="targetSource" ref="poolTargetSource"/>
                <property name="interceptorNames" value="myInterceptor"/>
            </bean>

注意目标对象--例子里的“businessObjectTarget”--必须是个原型。 这允许PoolingTargetSource的实现在必要时为目标创建新的实例来增大池的容量。 查看AbstractPoolingTargetSource和你想要使用的具体子类的Javadoc获取更多关于它属性的信息：maxSize是最基础的，而且永远都要求被提供。

在这个例子里，“myInterceptor”是一个拦截器的名字，这个拦截器需要在同一个IoC上下文中被定义。然而，定义对拦截器进行池化是不必要的。 如果你想要的只是池化而没有其它通知，就不要设置interceptorNames属性。

可以配置Spring来把任何被池化对象转型到org.springframework.aop.target.PoolingConfig接口， 这通过一个introduction暴露配置以及当前池的大小。你需要像这样定义一个通知器：

<bean id="poolConfigAdvisor" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
                <property name="targetObject" ref="poolTargetSource"/>
                <property name="targetMethod" value="getPoolingConfigMixin"/>
            </bean>

这个通知器可以通过调用AbstractPoolingTargetSource类上的一个方便的方法来获得，因此这里使用MethodInvokingFactoryBean。 这个通知器名（这里是“poolConfigAdvisor”）必须在提供被池化对象的ProxyFactoryBean里的拦截器名列表里中。

转型看起来像这样：

PoolingConfig conf = (PoolingConfig) beanFactory.getBean("businessObject");
        System.out.println("Max pool size is " + conf.getMaxSize());

	Note
	池化无状态服务对象通常是不必要的。我们不认为这（池化）应当是缺省的选择，因为多数无状态对象是先天线程安全的，如果资源被缓存，那么对实例进行池化会引起很多问题。

使用自动代理时池化更加简单。可以为任何自动代理创建器设置所使用的TargetSource

建立一个“原型”目标源和池化TargetSource很相似。在这个例子里，当每次方法调用时，将创建一个目标的新实例。 虽然在新版本的JVM中创建一个新对象的代价并不高，但是把新对象织入（满足它的IoC依赖）可能是很昂贵的。因此如果没有很好的理由，你不应该使用这个方法。

为了做到这点，你可以把上面的poolTargetSource定义修改成下面的形式。（为了清楚说明，修改了bean的名字。）

<bean id="prototypeTargetSource" class="org.springframework.aop.target.PrototypeTargetSource">
  <property name="targetBeanName" ref="businessObjectTarget"/>
        </bean>

这里只有一个属性：目标bean的名字。TargetSource的实现使用继承来确保命名的一致性。就像池化目标源那样，目标bean必须是一个原型的bean定义。

如果你需要为每个进来的请求（即每个线程）创建一个对象，ThreadLocal目标源是很有用的。 ThreadLocal的概念提供了一个JDK范围的功能，这可以为一个线程透明的保存资源。建立一个 ThreadLocalTargetSource的过程和其它目标源几乎完全一样：

<bean id="threadlocalTargetSource" class="org.springframework.aop.target.ThreadLocalTargetSource">
  <property name="targetBeanName" value="businessObjectTarget"/>
        </bean>

	Note
	如果不正确的在一个多线程和多类加载器的环境里使用ThreadLocal，将带来严重的问题（可能潜在地导致内存泄漏）。 永远记住应该把一个threadlocal包装在其它的类里，并永远不要直接使用ThreadLocal本身（当然是除了threadlocal包装类之外）。 同时，永远记住正确的设置（set）和取消（unset）（后者仅仅需要调用ThreadLocal.set(null)）绑定到线程的本地资源。 取消在任何情况下都应该进行，否则也许会导致错误的行为。Spring的ThreadLocal支持将为你处理这个问题，所以如果没有其它正确的处理代码，永远应该考虑使用这个功能。