让我们从定义一些重要的AOP概念开始。这些术语不是Spring特有的。不幸的是，Spring的术语 不是特别地直观。而且，如果Spring使用自己的术语，这将使人更加迷惑。

各种通知类型包括:

Around通知是最通用的通知类型。大部分基于拦截的AOP框架，如Nanning和JBoss4，只提供 Around通知。

如同AspectJ，Spring提供所有类型的通知，我们推荐你使用最为合适的通知类型来实现需 要的行为。例如，如果只是需要用一个方法的返回值来更新缓存，你最好实现一个after returning 通知而不是around通知，虽然around通知也能完成同样的事情。使用最合适的通知类型使编程模型变 得简单，并能减少潜在错误。例如你不需要调用在around通知中所需使用的的MethodInvocation的 proceed()方法，因此就调用失败。

切入点的概念是AOP的关键，使AOP区别于其它使用拦截的技术。切入点使通知独立于OO的 层次选定目标。例如，提供声明式事务管理的around通知可以被应用到跨越多个对象的一组方法上。 因此切入点构成了AOP的结构要素。

Spring AOP用纯Java实现。它不需要特别的编译过程。Spring AOP不需要控制类装载器层次， 因此适用于J2EE web容器或应用服务器。

Spring目前支持拦截方法调用。成员变量拦截器没有实现，虽然加入成员变量拦截器支持并不破坏 Spring AOP核心API。

Spring提供代表切入点或各种通知类型的类。Spring使用术语advisor来 表示代表方面的对象，它包含一个通知和一个指定特定连接点的切入点。

各种通知类型有MethodInterceptor (来自AOP联盟的拦截器API)和定义在org.springframework.aop包中的 通知接口。所有通知必须实现org.aopalliance.aop.Advice标签接口。 取出就可使用的通知有 MethodInterceptor、 ThrowsAdvice、 BeforeAdvice和 AfterReturningAdvice。我们将在下面详细讨论这些通知类型。

Spring实现了AOP联盟的拦截器接口( http://www.sourceforge.net/projects/aopalliance). Around通知必须实现AOP联盟的org.aopalliance.intercept.MethodInterceptor 接口。这个接口的实现可以运行在Spring或其他AOP联盟兼容的实现中。目前JAC实现了AOP联盟的接 口，Nanning和Dynaop可能在2004年早期实现。

Spring默认使用JDK动态代理实现AOP代理。这使得任何接口或 接口的集合能够被代理。

Spring也可以是CGLIB代理。这可以代理类，而不是接口。如果业务对象没有实现一个接口， CGLIB被默认使用。但是作为一针对接口编程而不是类编程良好实践，业务对象 通常实现一个或多个业务接口。

也可以强制使用CGLIB：我们将在下面讨论，并且会解释为什么你会要这么做。

Spring的切入点模型能够使切入点独立于通知类型被重用。 同样的切入点有可能接受不同的 通知。

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代理创建的时候执行，避免在所有方法调用时都需要进行 测试。如果2个参数的匹配方法对某个方法返回true，并且MethodMatcher的 isRuntime()也返回true，那么3个参数的匹配方法将在每次方法调用的时候被调用。这使 切入点能够在目标通知被执行之前立即查看传递给方法调用的参数。

大部分MethodMatcher都是静态的，意味着isRuntime()方法 返回false。这种情况下3个参数的匹配方法永远不会被调用。

Spring支持的切入点的运算有: 值得注意的是 并 和 交。

并表示只要任何一个切入点匹配的方法。

交表示两个切入点都要匹配的方法。

并通常比较有用。

切入点可以用org.springframework.aop.support.Pointcuts 类的静态方法来组合，或者使用同一个包中的ComposablePointcut类。

Spring提供几个实用的切入点实现。一些可以直接使用。另一些需要子类化来实现应用相 关的切入点。

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

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

5.2.3.2. 动态切入点

动态切入点的演算代价比静态切入点高的多。它们不仅考虑静态信息，还要考虑方法的 参数。这意味着它们必须在每次方法调用的时候都被计算；并且不能缓存结果 ，因为参数是变化的。

这个主要的例子就是控制流切入点。

5.2.3.2.1. 控制流切入点

Spring的控制流切入点概念上和AspectJ的cflow 切入点一致，虽然没有其那么强大（当前没有办法指定一个切入点在另一个切入点后执行）。 一个控制流切入点匹配当前的调用栈。例如，连接点被 com.mycompany.web包或者 SomeCaller类中一个方法调用的时候，触发该切入点。控制流切入点的实现类是 org.springframework.aop.support.ControlFlowPointcut。

	注意
	控制流切入点是动态切入点中计算代价最高的。Java 1.4中, 它的运行开销是其他动态切入点的5倍。在Java 1.3中则超过10倍。

Spring提供非常实用的切入点的超类帮助你实现你自己的切入点。

因为静态切入点非常实用，你很可能子类化StaticMethodMatcherPointcut，如下所示。 这只需要实现一个抽象方法（虽然可以改写其它的方法来自定义行为）。

class TestStaticPointcut extends StaticMethodMatcherPointcut {

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

当然也有动态切入点的超类。

Spring 1.0 RC2或以上版本，自定义切入点可以用于任何类型的通知。

因为Spring中的切入点是Java类，而不是语言特性（如AspectJ），因此可以定义自定义切入点， 无论静态还是动态。但是，没有直接支持用AspectJ语法书写的复杂的切入点表达式。不过， Spring的自定义切入点也可以任意的复杂。

Spring的通知可以跨越多个被通知对象共享，或者每个被通知对象有自己的通知。这分别对应 per-class或per-instance 通知。

Per-class通知使用最为广泛。它适合于通用的通知，如事务adisor。它们不依赖被代理 的对象的状态，也不添加新的状态。它们仅仅作用于方法和方法的参数。

Per-instance通知适合于导入，来支持混入（mixin）。在这种情况下，通知添加状态到 被代理的对象。

可以在同一个AOP代理中混合使用共享和per-instance通知。

Spring提供几种现成的通知类型并可扩展提供任意的通知类型。让我们看看基本概念和 标准的通知类型。

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

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;
    }
}

public interface MethodBeforeAdvice extends BeforeAdvice {

    void before(Method m, Object[] args, Object target) throws Throwable;
}

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; 
    }
}

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

public  class RemoteThrowsAdvice implements ThrowsAdvice {

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

public static class ServletThrowsAdviceWithArguments implements ThrowsAdvice {

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

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 will all arguments
    }
}

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;
    }
}

public interface IntroductionInterceptor extends MethodInterceptor {

    boolean implementsInterface(Class intf);
}

public interface InterceptionIntroductionAdvisor extends InterceptionAdvisor {

    ClassFilter getClassFilter();

    IntroductionInterceptor getIntroductionInterceptor();

    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);
    }
}

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

使用ProxyFactoryBean或者其他IoC可知的类来创建AOP代理 的最重要的优点之一是IoC可以管理通知和切入点。这是一个非常的强大的功能，能够实 现其他AOP框架很难实现的特定的方法。例如，一个通知本身可以引用应用对象（除了目标对象， 它在任何AOP框架中都可以引用应用对象），这完全得益于依赖注入所提供的可插入性。

类似于Spring提供的绝大部分FactoryBean实现一样， ProxyFactoryBean也是一个javabean，我们可以利用它的属性来:

一些关键属性来自org.springframework.aop.framework.ProxyConfig ：它是所有AOP代理工厂的父类。这些关键属性包括：

其他ProxyFactoryBean特定的属性包括：

让我们来看一个简单的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.NopInterceptor">
</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>

请注意:person bean的interceptorNames属性提供一个String列表， 列出的是该ProxyFactoryBean使用的,在当前bean工厂定义的interceptor或者advisor的 名字(advisor,interceptor,before,after returning,和throws advice 对象皆可)。 Advisor在该列表中的次序很重要。

上面定义的“person”bean定义可以作为Person接口的实现来使用，如下所示:

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

在同一个IoC的上下文中，其他的bean可以依赖于Person接口，就象依赖于一个普通的java对象一样。

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

在这个例子里，PersonUser类暴露了一个类型为Person的属性。 只要是在用到该属性的地方，AOP代理都能透明的替代一个真实的Person实现。 但是，这个类可能是一个动态代理类。也就是有可能把它类型转换为一个Advised接口 (该接口在下面的章节中论述) 。

如果你需要代理的是类，而不是一个或多个接口，又该怎么办呢?

想象一下我们上面的例子，如果没有Person接口， 我们需要通知一个叫Person的类， 而且该类没有实现任何业务接口。在这种情况下，你可以配置Spring使用CGLIB代理， 而不是动态代理。你只要在上面的ProxyFactoryBean定义中把 它的proxyTargetClass属性改成true就行了。

只要你愿意，即使在有接口的情况下，你也可以强迫Spring使用CGLIB代理。

CGLIB代理是通过在运行期产生目标类的子类来进行工作的。 Spring可以配置这个生成的子类，来代理原始目标类的方法调用。这个子类是用 Decorator设计模式置入到advice中的。

CGLIB代理对于用户来说应该是透明的。然而，还有以下一些因素需要考虑：

CGLIB和动态代理在性能上有微小的区别，对Spring 1.0来说，后者稍快。 另外,以后可能会有变化。在这种情况下性能不是决定性因素

用Spring提供的jPetStore的示例应用 演示了TransactionProxyFactoryBean的使用方式。

TransactionProxyFactoryBean是ProxyConfig的子类， 因此基本配置信息是和ProxyFactoryBean共享的。 (见上面ProxyConfig的属性列表。)

下面的代码来自于JPetStore application，演示了ProxyFactoryBean是如何工作的。 跟ProxyFactoryBean一样，存在一个目标bean的定义。 类的依赖关系定义在代理工厂bean定义中（petStore），而不是普通Java对象（petStoreTarget）。

TransactionProxyFactoryBean需要设置一个target属性， 还需要设置“transactionAttributes”， “transactionAttributes”用来指定需要事务化 处理的方法，还有要求的传播方式和其他设置:

<bean id="petStoreTarget" class="org.springframework.samples.jpetstore.domain.logic.PetStoreImpl">
    <property name="accountDao"><ref bean="accountDao"/></property>
    <!-- Other dependencies omitted -->
</bean>

<bean id="petStore" 
    class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
    <property name="transactionManager"><ref bean="transactionManager"/></property>
    <property name="target"><ref local="petStoreTarget"/></property>
    <property name="transactionAttributes">
        <props>
            <prop key="insert*">PROPAGATION_REQUIRED</prop>
            <prop key="update*">PROPAGATION_REQUIRED</prop>
            <prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
        </props>
    </property>
</bean>

TransactionProxyFactoryBean自动创建一个事务advisor， 该advisor包括一个基于事务属性的切入点。因此只有事务性的方法被通知。

TransactionProxyFactoryBean使用preInterceptors和 postInterceptors属性指定“pre”和“post”通知。它们将拦截器，通知和Advisor数组放置 在事务拦截器前后的拦截器链中。使用XML格式的bean定义中的<list>元素定义，就 象下面一样：

<property name="preInterceptors">
    <list>
        <ref local="authorizationInterceptor"/>
        <ref local="notificationBeforeAdvice"/>
    </list>
</property>
<property name="postInterceptors">
    <list>
        <ref local="myAdvisor"/>
    </list>
</property>

这些属性可以加到上面的“petStore”的bean定义里。一个通用用法是将事务和声明式 安全组合在一起使用：一个和EJB提供的类似的方法。

因为使用前拦截器和后拦截器时，用的是真正的实例引用，而不象在 ProxyFactoryBean中用的bean的名字，因此它们只能用于共享实例的通知。 因此它们不能用在有状态的通知中：例如，在mixin中。这和TransactionProxyFactoryBean的要求是 一致的。如果你需要更复杂的，可以定制的AOP，你可以考虑使用普通的ProxyFactoryBean， 或者是自动代理生成器（参考下面）。

TransactionProxyFactoryBean依赖于由它的transactionManager 属性指定的TransactionManager。 这种事务管理方式是可插拔的，基于JTA，JDBC或者其他事务管理策略皆可。 这与Spring的事务抽象层有关，而不在于AOP本身。我们将在下一章中讨论事务机制。

其它有一些专门的代理用于创建EJB代理，使得EJB的“业务方法”的接口可以被调用代码直接使用。 调用代码并不需要进行JNDI查找或使用EJB的创建方法：这是在可读性和架构灵活性方面的重大提高。

进一步请参考本手册内的Spring的EJB业务。

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

<bean id="jdkBeanNameProxyCreator" 
    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 id="autoProxyCreator"
    class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
</bean>

<bean id="txAdvisor"
    autowire="constructor"
    class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
    <property name="order"><value>1</value></property>
</bean>

<bean id="customAdvisor"
    class="com.mycompany.MyAdvisor">
</bean>

<bean id="businessObject1"
    class="com.mycompany.BusinessObject1">
    <!-- Properties omitted -->
</bean>

<bean id="businessObject2"
    class="com.mycompany.BusinessObject2">
</bean>

一种特别重要的自动代理类型是由元数据驱动的。这和.NET的ServicedComponents编程框架 非常类似。它没有象EJB那样使用XML部署描述，事务管理和其它企业级业务的配置都是定义在源代码级的属性上。

在这种情况下，你可以使用DefaultAdvisorAutoProxyCreator，以及可以读取元数据属性的 Advisor。元数据细节定义在候选advisor的切入点部分，而不是自动代理创建类本身。

这是DefaultAdvisorAutoProxyCreator的一种特殊情况，但是它本身而言是值得考虑的。 （可以读取元数据的代码处于advisor的切入点中，而不是AOP框架本身。）

jPetStore示例应用的/attributes目录演示了属性驱动的自动代理的使用。在这个例子中， 没有必要使用TransactionProxyFactoryBean。仅仅在业务对象上定义业务属性就足够了，因为 使用了可知元数据的切入点。bean定义在/WEB-INF/declarativeServices.xml中，包括下 面的代码。注意这是通用的，可以在jPetStore以外的地方使用：

<bean id="autoproxy" 
    class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
</bean>

<bean id="transactionAttributeSource"
    class="org.springframework.transaction.interceptor.AttributesTransactionAttributeSource"
    autowire="constructor">
</bean>

<bean id="transactionInterceptor"
    class="org.springframework.transaction.interceptor.TransactionInterceptor"
    autowire="byType">
</bean>

<bean id="transactionAdvisor"
    class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor"
    autowire="constructor" >
</bean>

<bean id="attributes"
    class="org.springframework.metadata.commons.CommonsAttributes"
/>

DefaultAdvisorAutoProxyCreator bean定义－－在这种情况下称作“advisor”，但是名字 无关紧要－－会在当前的应用上午中选择所有符合的切入点。在这个例子中，类型为 TransactionAttributeSourceAdvisor的“transactionAdvisor”bean定义将会应用于包含事务属性 的类或方法。TransactionAttributeSourceAdvisor通过构造函数依赖于TransactionInterceptor。这个例子通过自动 装配来解析它。AttributesTransactionAttributeSource依赖于 org.springframework.metadata.Attributes接口的一个实现。在这段代码中，“attributes” bean使用Jakarta Commons Attributes API来获取属性信息。（应用代码必须使用Commons Attributes编译任务编译。）

这里定义的TransactionInterceptor依赖于一个 PlatformTransactionManager定义，它并没有被包括在这个通用的文件中（虽然应该是这样）， 这是因为它是和应用的事务需求相关的（一般地，是想这个例子中的JTA，或者Hibernate，JDO 或JDBC）：

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

这个机制具有可扩展性。它可以基于定制的属性来使用自动代理。你需要：

这些advisor可能对每个被通知类都是唯一的（例如，maxin）。它们仅仅需要被定义成 prototype bean，而不是singleton bean。例如，Spring的测试套件中的LockMixin 引入拦截器可以和一个属性驱动切入点一起来定位一个maxin，就象这里演示的。我们使用JavaBean配置的 普通的DefaultPointcutAdvisor：

<bean id="lockMixin"
    class="org.springframework.aop.LockMixin"
    singleton="false"
/>

<bean id="lockableAdvisor"
    class="org.springframework.aop.support.DefaultPointcutAdvisor"
    singleton="false"
>
    <property name="pointcut">
        <ref local="myAttributeAwarePointcut"/>
    </property>
    <property name="advice">
        <ref local="lockMixin"/>
    </property>
</bean>

<bean id="anyBean" class="anyclass" ...

如果知道属性的切入点符合anyBean或者其它bean定义中的任何方法，这个maxin 将被应用。注意，lockMixin和lockableAdvisor定义都是 prototype的。myAttributeAwarePointcut切入点可以被定义成singleton，因为它不为 不同的被通知对象保存状态。

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>

<bean id="swapper" 
    class="org.springframework.aop.target.HotSwappableTargetSource">
    <constructor-arg><ref local="initialTarget"/></constructor-arg>
</bean>

<bean id="swappable" 
    class="org.springframework.aop.framework.ProxyFactoryBean"
>
    <property name="targetSource">
        <ref local="swapper"/>
    </property>
</bean>

上面的swap()调用会修改swappable这个bean的目标。持有对这个bean应用的客户端 将不会知道这个变化，但会立刻转为使用新的目标对象。

虽然这个例子没有添加任何通知－－使用TargetSource也没必要添加通知－－ 当然任何TargetSource都可以和任何一种通知一起使用。

使用支持池的目标源提供了一种和无状态的session EJB类似的编程模式，在无状态的session EJB中，维护了 一个相同实例的池，提供从池中获取可用对象的方法。

Spring的池和SLSB的池之间的重要区别在于Spring的池可以被应用到任何普通Java对象。就象Spring的通用 的做法，这个业务也可以以非侵入的方式被应用。

Spring直接支持Jakarta Commons Pool 1.1，它是一种非常高效的池实现。使用这个功能，你需要在你的应用的 classpath中添加commons-pool的Jar文件。也可以直接继承 org.springframework.aop.target.AbstractPoolingTargetSource来支持其它池API。

下面是一个配置的例子：

<bean id="businessObjectTarget" class="com.mycompany.MyBusinessObject" 
    singleton="false">
    ... properties omitted
</bean>

<bean id="poolTargetSource" 
    class="org.springframework.aop.target.CommonsPoolTargetSource">
    <property name="targetBeanName"><value>businessObject</value></property>
    <property name="maxSize"><value>25</value></property>
</bean>

<bean id="businessObject" 
    class="org.springframework.aop.framework.ProxyFactoryBean"
>
    <property name="targetSource"><ref local="poolTargetSource"/></property>
    <property name="interceptorNames"><value>myInterceptor</value></property>
</bean>

注意例子中的目标对象“businessObjectTarget”必须是prototype。这样在 PoolingTargetSource的实现在扩大池容量的时候可以创建目标的新实例。关于这些属性的 信息可以参考AbstractPoolingTargetSource和子类的Javadoc。maxSize是最基本的属性， 被保证总是存在。

在这种情况下，名字为“myInterceptor”的拦截器需要定义在同一个IoC上下文中。但是，并不一定需要 指定拦截器也用池。如果你仅需要池，并且没有其它通知，可以根本不设置属性interceptorNames。

也可以配置Spring以便可以将任何池化的对象转换类型为 org.springframework.aop.target.PoolingConfig接口。通过这个接口的一个引入，可以得到 配置信息和池的当前大小。你需要这样定义一个advisor：

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

通过调用AbstractPoolingTargetSource类上的方法，可以得到这个advisor， 因此使用MethodInvokingFactoryBean。这个advisor的名字（“poolConfigAdvisor”）必须在暴露池化对象的 This advisor is obtained by calling a convenience method on the ProxyFactoryBean中的拦截器名字列表中。

这个类型转换就象下面：

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

简单的池也可以使用自动代理。任何自动代理生成器都可以设置TargetSources。

设置“prototype”目标源和支持池的目标源类似。在每次方法调用的时候都会创建一个新的目标实例。 虽然在现代JVM中创建对象的代价不是很高，但是装配新对象的代价可能更高（为了maz满足它的IoC依赖关系）。 因此没有好的理由不应该使用这个方法。

为了这么做，你可以修改上面的的poolTargetSource定义，就向下面一样。 （为了清晰起见，我修改了名字。）

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

只有一个属性：目标bean的名字。在TargetSource实现中使用继承是为了保证命名的一致性。就象支持池的 目标源一样，目标bean必须是一个prototype的bean定义。