讓我們從定義一些重要的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>
            

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定義。