AOP概念理解
Spring AOP概念理解
1.我所知道的aop
初看aop,上来就是一大堆术语，而且还有个拉风的名字，面向切面编程，都说是OOP的一种有益补充等等。一下子让你不知所措，心想着：怪不得很多人都和我说aop多难多难。当我看进去以后，我才发现：它就是一些java基础上的朴实无华的应用，包括ioc，包括许许多多这样的名词，都是万变不离其宗而已。
2.为什么用aop
1就是为了方便，看一个国外很有名的大师说，编程的人都是“懒人”，因为他把自己做的事情都让程序做了。用了aop能让你少写很多代码，这点就够充分了吧
2就是为了更清晰的逻辑，可以让你的业务逻辑去关注自己本身的业务，而不去想一些其他的事情，这些其他的事情包括：安全，事物，日志等。
3.那些aop的术语
初看这么多术语，一下子都不好接受，慢慢来，很快就会搞懂。
1.通知（Advice）
就是你想要的功能，也就是上面说的 安全，事物，日志等。你给先定义好把，然后在想用的地方用一下。
2.连接点（JoinPoint）
这个更好解释了，就是spring允许你使用通知的地方，那可真就多了，基本每个方法的前，后（两者都有也行），或抛出异常时都可以是连接点，spring只支持方法连接点.其他如aspectJ还可以让你在构造器或属性注入时都行，不过那不是咱关注的，只要记住，和方法有关的前前后后（抛出异常），都是连接点。
3.切入点（Pointcut）
上面说的连接点的基础上，来定义切入点，你的一个类里，有15个方法，那就有几十个连接点了对把，但是你并不想在所有方法附近都使用通知（使用叫织入，以后再说），你只想让其中的几个，在调用这几个方法之前，之后或者抛出异常时干点什么，那么就用切点来定义这几个方法，让切点来筛选连接点，选中那几个你想要的方法。
4.切面（Aspect）
切面是通知和切入点的结合。现在发现了吧，没连接点什么事情，连接点就是为了让你好理解切点，搞出来的，明白这个概念就行了。通知说明了干什么和什么时候干（什么时候通过方法名中的before,after，around等就能知道），而切入点说明了在哪干（指定到底是哪个方法），这就是一个完整的切面定义。
5.引入（introduction）
允许我们向现有的类添加新方法属性。这不就是把切面（也就是新方法属性：通知定义的）用到目标类中吗
6.目标（target）
引入中所提到的目标类，也就是要被通知的对象，也就是真正的业务逻辑，他可以在毫不知情的情况下，被咱们织入切面。而自己专注于业务本身的逻辑。
7.代理(proxy)
怎么实现整套aop机制的，都是通过代理，这个一会给细说。
8.织入(weaving)
把切面应用到目标对象来创建新的代理对象的过程。有3种方式，spring采用的是运行时，为什么是运行时，后面解释。
关键就是：切点定义了哪些连接点会得到通知
4.我所理解的aop原理
spring用代理类包裹切面，把他们织入到Spring管理的bean中。也就是说代理类伪装成目标类，它会截取对目标类中方法的调用，让调用者对目标类的调用都先变成调用伪装类，伪装类中就先执行了切面，再把调用转发给真正的目标bean。
现在可以自己想一想，怎么搞出来这个伪装类，才不会被调用者发现（过JVM的检查，JAVA是强类型检查，哪里都要检查类型）。
1.实现和目标类相同的接口，我也实现和你一样的接口，反正上层都是接口级别的调用，这样我就伪装成了和目标类一样的类（实现了同一接口，咱是兄弟了），也就逃过了类型检查，到java运行期的时候，利用多态的后期绑定（所以spring采用运行时），伪装类（代理类）就变成了接口的真正实现，而他里面包裹了真实的那个目标类，最后实现具体功能的还是目标类，只不过伪装类在之前干了点事情（写日志，安全检查，事物等）。
这就好比，一个人让你办件事，每次这个时候，你弟弟就会先出来，当然他分不出来了，以为是你，你这个弟弟虽然办不了这事，但是他知道你能办，所以就答应下来了，并且收了点礼物（写日志），收完礼物了，给把事给人家办了啊，所以你弟弟又找你这个哥哥来了，最后把这是办了的还是你自己。但是你自己并不知道你弟弟已经收礼物了，你只是专心把这件事情做好。
顺着这个思路想，要是本身这个类就没实现一个接口呢，你怎么伪装我，我就压根没有机会让你搞出这个双胞胎的弟弟，那么就用第2种代理方式，创建一个目标类的子类，生个儿子，让儿子伪装我
2.生成子类调用，这次用子类来做为伪装类，当然这样也能逃过JVM的强类型检查，我继承的吗，当然查不出来了，子类重写了目标类的所有方法，当然在这些重写的方法中，不仅实现了目标类的功能，还在这些功能之前，实现了一些其他的（写日志，安全检查，事物等）。
这次的对比就是，儿子先从爸爸那把本事都学会了，所有人都找儿子办事情，但是儿子每次办和爸爸同样的事之前，都要收点小礼物（写日志），然后才去办真正的事。当然爸爸是不知道儿子这么干的了。这里就有件事情要说，某些本事是爸爸独有的(final的)，儿子学不了，学不了就办不了这件事，办不了这个事情，自然就不能收人家礼了。
前一种兄弟模式，spring会使用JDK的java.lang.reflect.Proxy类，它允许Spring动态生成一个新类来实现必要的接口，织入通知，并且把对这些接口的任何调用都转发到目标类。
后一种父子模式，spring使用CGLIB库生成目标类的一个子类，在创建这个子类的时候，spring织入通知，并且把对这个子类的调用委托到目标类。
相比之下，还是兄弟模式好些，他能更好的实现松耦合，尤其在今天都高喊着面向接口编程的情况下，父子模式只是在没有实现接口的时候，也能织入通知，应当做一种例外。
6.1. 简介
面向切面编程（AOP）提供另外一种角度来思考程序结构，通过这种方式弥补了面向对象编程（OOP）的不足。 除了类（classes）以外，AOP提供了 切面。切面对关注点进行模块化，例如横切多个类型和对象的事务管理。 （这些关注点术语通常称作 横切（crosscutting） 关注点。）
Spring的一个关键的组件就是 AOP框架。 尽管如此，Spring IoC容器并不依赖于AOP，这意味着你可以自由选择是否使用AOP，AOP提供强大的中间件解决方案，这使得Spring IoC容器更加完善。
Spring 2.0 AOP
Spring 2.0 引入了一种更加简单并且更强大的方式来自定义切面，用户可以选择使用基于模式（schema-based）的方式或者使用@AspectJ注解。 对于新的应用程序，如果用户使用Java 5开发，我们推荐用户使用@AspectJ风格，否则可以使用基于模式的风格。 这两种风格都完全支持通知（Advice）类型和AspectJ的切入点语言，虽然实际上仍然使用Spring AOP进行织入（Weaving）。
本章主要讨论Spring 2.0对基于模式和基于@AspectJ的AOP支持。 Spring 2.0完全保留了对Spring 1.2的向下兼容性，下一章 将讨论Spring 1.2 API所提供的底层的AOP支持。
Spring中所使用的AOP：
提供声明式企业服务，特别是为了替代EJB声明式服务。 最重要的服务是 声明性事务管理（declarative transaction management） ， 这个服务建立在Spring的抽象事务管理（transaction abstraction）之上。
允许用户实现自定义的切面，用AOP来完善OOP的使用。
这样你可以把Spring AOP看作是对Spring的一种增强，它使得Spring可以不需要EJB就能提供声明式事务管理；或者也可以使用Spring AOP框架的全部功能来实现自定义的切面。
本章首先 介绍了AOP的概念，无论你打算采用哪种风格的切面声明，这个部分都值得你一读。 本章剩下的部分将着重于Spring 2.0对AOP的支持； 下一章 提供了关于Spring 1.2风格的AOP概述，也许你已经在其他书本，文章以及已有的应用程序中碰到过这种AOP风格。
如果你只打算使用通用的声明式服务或者预先打包的声明式中间件服务，例如缓冲池（pooling）， 那么你不必不直接使用Spring AOP，而本章的大部分内容也可以直接跳过。
6.1.1. AOP概念
首先让我们从定义一些重要的AOP概念开始。这些术语不是Spring特有的。 不幸的是，Spring术语并不是特别的直观；如果Spring使用自己的术语，将会变得更加令人困惑。
切面（Aspect）： 一个关注点的模块化，这个关注点可能会横切多个对象。事务管理是J2EE应用中一个关于横切关注点的很好的例子。 在Spring AOP中，切面可以使用通用类（基于模式的风格） 或者在普通类中以 @Aspect 注解（@AspectJ风格）来实现。
连接点（Joinpoint）： 在程序执行过程中某个特定的点，比如某方法调用的时候或者处理异常的时候。 在Spring AOP中，一个连接点 总是 代表一个方法的执行。 通过声明一个 org.aspectj.lang.JoinPoint 类型的参数可以使通知（Advice）的主体部分获得连接点信息。
通知（Advice）： 在切面的某个特定的连接点（Joinpoint）上执行的动作。通知有各种类型，其中包括“around”、“before”和“after”等通知。 通知的类型将在后面部分进行讨论。许多AOP框架，包括Spring，都是以拦截器做通知模型，并维护一个以连接点为中心的拦截器链。
切入点（Pointcut）： 匹配连接点（Joinpoint）的断言。通知和一个切入点表达式关联，并在满足这个切入点的连接点上运行（例如，当执行某个特定名称的方法时）。 切入点表达式如何和连接点匹配是AOP的核心：Spring缺省使用AspectJ切入点语法。
引入（Introduction）： （也被称为内部类型声明（inter-type declaration））。声明额外的方法或者某个类型的字段。 Spring允许引入新的接口（以及一个对应的实现）到任何被代理的对象。 例如，你可以使用一个引入来使bean实现 IsModified 接口，以便简化缓存机制。
目标对象（Target Object）： 被一个或者多个切面（aspect）所通知（advise）的对象。也有人把它叫做 被通知（advised） 对象。 既然Spring AOP是通过运行时代理实现的，这个对象永远是一个 被代理（proxied） 对象。
AOP代理（AOP Proxy）： AOP框架创建的对象，用来实现切面契约（aspect contract）（包括通知方法执行等功能）。 在Spring中，AOP代理可以是JDK动态代理或者CGLIB代理。 注意：Spring 2.0最新引入的基于模式（schema-based）风格和@AspectJ注解风格的切面声明，对于使用这些风格的用户来说，代理的创建是透明的。
织入（Weaving）： 把切面（aspect）连接到其它的应用程序类型或者对象上，并创建一个被通知（advised）的对象。 这些可以在编译时（例如使用AspectJ编译器），类加载时和运行时完成。 Spring和其他纯Java AOP框架一样，在运行时完成织入。
通知的类型：
前置通知（Before advice）： 在某连接点（join point）之前执行的通知，但这个通知不能阻止连接点前的执行（除非它抛出一个异常）。
返回后通知（After returning advice）： 在某连接点（join point）正常完成后执行的通知：例如，一个方法没有抛出任何异常，正常返回。
抛出异常后通知（After throwing advice）： 在方法抛出异常退出时执行的通知。
后通知（After (finally) advice）： 当某连接点退出的时候执行的通知（不论是正常返回还是异常退出）。
环绕通知（Around Advice）： 包围一个连接点（join point）的通知，如方法调用。这是最强大的一种通知类型。 环绕通知可以在方法调用前后完成自定义的行为。它也会选择是否继续执行连接点或直接返回它们自己的返回值或抛出异常来结束执行。
环绕通知是最常用的一种通知类型。大部分基于拦截的AOP框架，例如Nanning和JBoss4，都只提供环绕通知。
跟AspectJ一样，Spring提供所有类型的通知，我们推荐你使用尽量简单的通知类型来实现需要的功能。 例如，如果你只是需要用一个方法的返回值来更新缓存，虽然使用环绕通知也能完成同样的事情， 但是你最好使用After returning通知而不是环绕通知。 用最合适的通知类型可以使得编程模型变得简单，并且能够避免很多潜在的错误。 比如，你不需要调用 JoinPoint（用于Around Advice）的 proceed() 方法，就不会有调用的问题。
在Spring 2.0中，所有的通知参数都是静态类型，因此你可以使用合适的类型（例如一个方法执行后的返回值类型）作为通知的参数而不是使用一个对象数组。
切入点（pointcut）和连接点（join point）匹配的概念是AOP的关键，这使得AOP不同于其它仅仅提供拦截功能的旧技术。 切入点使得定位通知（advice）可独立于OO层次。 例如，一个提供声明式事务管理的around通知可以被应用到一组横跨多个对象中的方法上（例如服务层的所有业务操作）。
6.1.2. Spring AOP的功能和目标
Spring AOP用纯Java实现。它不需要专门的编译过程。Spring AOP不需要控制类装载器层次，因此它适用于J2EE web容器或应用服务器。
Spring目前仅支持使用方法调用作为连接点（join point）（在Spring bean上通知方法的执行）。 虽然可以在不影响到Spring AOP核心API的情况下加入对成员变量拦截器支持，但Spring并没有实现成员变量拦截器。 如果你需要把对成员变量的访问和更新也作为通知的连接点，可以考虑其它语法的Java语言，例如AspectJ。
Spring实现AOP的方法跟其他的框架不同。Spring并不是要尝试提供最完整的AOP实现（尽管Spring AOP有这个能力）， 相反的，它其实侧重于提供一种AOP实现和Spring IoC容器的整合，用于帮助解决在企业级开发中的常见问题。
因此，Spring AOP通常都和Spring IoC容器一起使用。 Aspect使用普通的bean定义语法（尽管Spring提供了强大的“自动代理（autoproxying）”功能）： 与其他AOP实现相比这是一个显著的区别。有些事使用Spring AOP是无法轻松或者高效的完成的，比如说通知一个细粒度的对象。 这种时候，使用AspectJ是最好的选择。不过经验告诉我们： 于大多数在J2EE应用中遇到的问题，只要适合AOP来解决的，Spring AOP都没有问题，Spring AOP提供了一个非常好的解决方案。
Spring AOP从来没有打算通过提供一种全面的AOP解决方案来取代AspectJ。 我们相信无论是基于代理（proxy-based ）的框架比如说Spring亦或是full-blown的框架比如说是AspectJ都是很有价值的，他们之间的关系应该是互补而不是竞争的关系。 Spring 2.0可以无缝的整合Spring AOP，IoC 和AspectJ，使得所有的AOP应用完全融入基于Spring的应用体系。 这样的集成不会影响Spring AOP API或者AOP Alliance API；Spring AOP保留了向下兼容性。接下来的一章会详细讨论Spring AOP API。
6.1.3. Spring的AOP代理
Spring缺省使用J2SE 动态代理（dynamic proxies）来作为AOP的代理。这样任何接口都可以被代理。
Spring也支持使用CGLIB代理. 对于需要代理类而不是代理接口的时候CGLIB代理是很有必要的。 如果一个业务对象并没有实现一个接口，默认就会使用CGLIB。 此外，面向接口编程 也是一个最佳实践，业务对象通常都会实现一个或多个接口。
此外，还可以强制的使用CGLIB：我们将会在以后讨论这个问题，解释问什么你会要这么做。
在Spring 2.0之后，Spring可能会提供多种其他类型的AOP代理，包括了完整的生成类。这不会影响到编程模型。
6.2. @AspectJ支持
如果你使用Java 5的话，推荐使用Spring提供的@AspectJ切面支持，通过这种方式声明Spring AOP中使用的切面。 "@AspectJ"使用了Java 5的注解，可以将切面声明为普通的Java类。 AspectJ 5发布的 AspectJ project 中引入了这种@AspectJ风格。 Spring 2.0 使用了和AspectJ 5一样的注解，使用了AspectJ 提供的一个库来做切点（pointcut）解析和匹配。 但是，AOP在运行时仍旧是纯的Spring AOP，并不依赖于AspectJ 的编译器或者织入器（weaver）。
使用AspectJ的编译器或者织入器（weaver）的话就可以使用完整的AspectJ 语言，我们将在 Section 6.7, “在Spring应用中使用AspectJ” 中讨论这个问题。
6.2.1. 启用@AspectJ支持
为了在Spring配置中使用@AspectJ aspects，你必须首先启用Spring对基于@AspectJ aspects的配置支持，自动代理（autoproxying）基于通知是否来自这些切面。 自动代理是指Spring会判断一个bean是否使用了一个或多个切面通知，并据此自动生成相应的代理以拦截其方法调用，并且确认通知是否如期进行。
通过在你的Spring的配置中引入下列元素来启用Spring对@AspectJ的支持：
如果你正在使用DTD，你仍旧可以通过在你的application context中添加如下定义来启用@AspectJ支持：
6.2.2. 声明一个切面
在启用@AspectJ支持的情况下，在application context中定义的任意带有一个@Aspect切面（拥有@Aspect注解）的bean都将被Spring自动识别并用于配置在Spring AOP。 以下例子展示了为了完成一个不是非常有用的切面所需要的最小定义：
下面是在application context中的一个常见的bean定义，这个bean指向一个使用了 @Aspect 注解的bean类：
下面是 NotVeryUsefulAspect 类定义，使用了 org.aspectj.lang.annotation.Aspect 注解。
package org.xyz;
import org.aspectj.lang.annotation.Aspect;
@Aspect
public class NotVeryUsefulAspect {
}切面（用 @Aspect 注解的类）和其他类一样有方法和字段定义。他们也可能包括切入点，通知和引入（inter-type）声明。
6.2.3. 声明一个切入点（pointcut）
回想一下，切入点决定了连接点关注的内容，使得我们可以控制通知什么执行。 Spring AOP只支持Spring bean方法执行连接点。所以你可以把切入点看做是匹配Spring bean上的方法执行。 一个切入点声明有两个部分：一个包含名字和任意参数的签名，还有一个切入点表达式，该表达式决定了我们关注那个方法的执行。 在@AspectJ中，一个切入点实际就是一个普通的方法定义提供的一个签名，并且切入点表达式使用 @Pointcut注解来表示。 这个方法的返回类型必须是 void。 如下的例子定义了一个切入点'transfer'，这个切入点匹配了任意名为"transfer"的方法执行：
@Pointcut("execution(* transfer(..))")
private void transfer() {}切入点表达式，也就是 @Pointcut 注解的值，是正规的AspectJ 5切入点表达式。 如果你想要更多了解AspectJ的 切入点语言，请参见 AspectJ 编程指南（如果要了解基于Java 5的扩展请参阅 AspectJ 5 开发手册） 或者其他人写的关于AspectJ的书，例如Colyer et. al.著的《Eclipse AspectJ》或者Ramnivas Laddad著的《AspectJ in Action》。
6.2.3.1. 支持的切入点指定者
Spring AOP 支持在切入点表达式中使用如下的AspectJ切入点指定者：
其他的切入点类型
完整的AspectJ切入点语言支持额外的切入点指定者，但是Spring不支持这个功能。 他们分别是call, initialization, preinitialization, staticinitialization, get, set, handler, adviceexecution, withincode, cflow, cflowbelow, if, @this 和 @withincode。 在Spring AOP中使用这些指定者将会导致抛出IllegalArgumentException异常。
Spring AOP支持的切入点指定者可能在将来的版本中得到扩展，不但支持更多的AspectJ 切入点指定者（例如"if"），还会支持某些Spring特有的切入点指定者，比如"bean"（用于匹配bean的名字）。
execution - 匹配方法执行的连接点，这是你将会用到的Spring的最主要的切入点指定者。
within - 限定匹配特定类型的连接点（在使用Spring AOP的时候，在匹配的类型中定义的方法的执行）。
this - 限定匹配特定的连接点（使用Spring AOP的时候方法的执行），其中bean reference（Spring AOP 代理）是指定类型的实例。
target - 限定匹配特定的连接点（使用Spring AOP的时候方法的执行），其中目标对象（被代理的appolication object）是指定类型的实例。
args - 限定匹配特定的连接点（使用Spring AOP的时候方法的执行），其中参数是指定类型的实例。
@target - 限定匹配特定的连接点（使用Spring AOP的时候方法的执行），其中执行的对象的类已经有指定类型的注解。
@args - 限定匹配特定的连接点（使用Spring AOP的时候方法的执行），其中实际传入参数的运行时类型有指定类型的注解。
@within - 限定匹配特定的连接点，其中连接点所在类型已指定注解（在使用Spring AOP的时候，所执行的方法所在类型已指定注解）。
@annotation - 限定匹配特定的连接点（使用Spring AOP的时候方法的执行），其中连接点的主题有某种给定的注解。
因为Spring AOP限制了连接点必须是方法执行级别的，pointcut designators的讨论也给出了一个定义，这个定义和AspectJ的编程指南中的定义相比显得更加狭窄。 除此之外，AspectJ它本身有基于类型的语义，在执行的连接点'this'和'target'都是指同一个对象，也就是执行方法的对象。 Spring AOP是一个基于代理的系统，并且严格区分代理对象本身（对应于'this'）和背后的目标对象（对应于'target'）
6.2.3.2. 合并切入点表达式
切入点表达式可以使用using '&&', '||' 和 '!'来合并.还可以通过名字来指向切入点表达式。 以下的例子展示了三种切入点表达式： anyPublicOperation（在一个方法执行连接点代表了任意public方法的执行时匹配）； inTrading（在一个代表了在交易模块中的任意的方法执行时匹配） 和 tradingOperation（在一个代表了在交易模块中的任意的公共方法执行时匹配）。
@Pointcut("execution(public * *(..))")
private void anyPublicOperation() {}
@Pointcut("within(com.xyz.someapp.trading..*")
private void inTrading() {}
@Pointcut("anyPublicOperation() && inTrading()")
private void tradingOperation() {}就上所示的，从更小的命名组件来构建更加复杂的切入点表达式是一种最佳实践。 当用名字来指定切入点时使用的是常见的Java成员可视性访问规则。 （比如说，你可以在同一类型中访问私有的切入点，在继承关系中访问受保护的切入点，可以在任意地方访问公共切入点。 成员可视性访问规则不影响到切入点的 匹配。
在AspectJ 1.5.1中有一个bug （#140357）有时候可能会导致Spring所使用的AspectJ切入点解析失败， 即使用一个已命名的切入点来引用到另一个同类型的切入点的时候。 在AspectJ的开发中已经解决这个bug，可以在AspectJ的下载页面得到。在1.5.2发布时将会包含这一fix。 如果你遇到了这个问题，你可以去下载AspectJ的开发构建包，并且更新你的 aspectjweaver.jar，这是在AspectJ 1.5.2发布前的临时解决方案。
6.2.3.3. 共享常见的切入点（pointcut）定义
当开发企业级应用的时候，你通常会想要从几个切面来参考模块化的应用和特定操作的集合。 我们推荐定义一个“SystemArchitecture”切面来捕捉常见的切入点表达式。一个典型的切面可能看起来像下面这样：
package com.xyz.someapp;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
@Aspect
public class SystemArchitecture {
/**
* A join point is in the web layer if the method is defined
* in a type in the com.xyz.someapp.web package or any sub-package
* under that.
*/
@Pointcut("within(com.xyz.someapp.web..*)")
public void inWebLayer() {}
/**
* A join point is in the service layer if the method is defined
* in a type in the com.xyz.someapp.service package or any sub-package
* under that.
*/
@Pointcut("within(com.xyz.someapp.service..*)")
public void inServiceLayer() {}
/**
* A join point is in the data access layer if the method is defined
* in a type in the com.xyz.someapp.dao package or any sub-package
* under that.
*/
@Pointcut("within(com.xyz.someapp.dao..*)")
public void inDataAccessLayer() {}
/**
* A business service is the execution of any method defined on a service
* interface. This definition assumes that interfaces are placed in the
* "service" package, and that implementation types are in sub-packages.
*
* If you group service interfaces by functional area (for example,
* in packages com.xyz.someapp.abc.service and com.xyz.def.service) then
* the pointcut expression "execution(* com.xyz.someapp..service.*.*(..))"
* could be used instead.
*/
@Pointcut("execution(* com.xyz.someapp.service.*.*(..))")
public void businessService() {}
/**
* A data access operation is the execution of any method defined on a
* dao interface. This definition assumes that interfaces are placed in the
* "dao" package, and that implementation types are in sub-packages.
*/
@Pointcut("execution(* com.xyz.someapp.dao.*.*(..))")
public void dataAccessOperation() {}
}示例中的切入点定义一个你可以在任何需要切入点表达式的地方可引用的切面。比如，为了使service层事务化，你可以写：
pointcut="com.xyz.someapp.SystemArchitecture.businessService()" advice-ref="tx-advice"/> 在 Section 6.3, “Schema-based AOP support” 中讨论 6.2.3.4. 示例 Spring AOP 用户可能会经常使用 execution pointcut designator。执行表达式的格式如下： execution(modifiers-pattern? ret-type-pattern declaring-type-pattern? name-pattern(param-pattern) throws-pattern?)除了返回类型模式，名字模式和参数模式以外，所有的部分都是可选的。 返回类型模式决定了方法的返回类型必须依次匹配一个连接点。 你会使用的最频繁的返回类型模式是 *，它代表了匹配任意的返回类型。 一个全称限定的类型名将只会匹配返回给定类型的方法。名字模式匹配的是方法名。 你可以使用 * 通配符作为所有或者部分命名模式。 参数模式稍微有点复杂：() 匹配了一个不接受任何参数的方法， 而 (..) 匹配了一个接受任意数量参数的方法（零或者更多）。 模式 (*) 匹配了一个接受一个任何类型的参数的方法。 模式 (*,String) 匹配了一个接受两个参数的方法，第一个可以是任意类型，第二个则必须是String类型。 请参见AspectJ编程指南的 Language Semantics 部分。 下面给出一些常见切入点表达式的例子。 任意公共方法的执行： execution(public * *(..))任何一个以“set”开始的方法的执行： execution(* set*(..))AccountService 接口的任意方法的执行： execution(* com.xyz.service.AccountService.*(..))定义在service包里的任意方法的执行： execution(* com.xyz.service.*.*(..))定义在service包或者子包里的任意方法的执行： execution(* com.xyz.service..*.*(..))在service包里的任意连接点（在Spring AOP中只是方法执行） ： within(com.xyz.service.*)在service包或者子包里的任意连接点（在Spring AOP中只是方法执行） ： within(com.xyz.service..*)实现了 AccountService 接口的代理对象的任意连接点（在Spring AOP中只是方法执行） ： this(com.xyz.service.AccountService)'this'在binding form中用的更多：- 请常见以下讨论通知的章节中关于如何使得代理对象可以在通知体内访问到的部分。 实现了 AccountService 接口的目标对象的任意连接点（在Spring AOP中只是方法执行） ： target(com.xyz.service.AccountService)'target'在binding form中用的更多：- 请常见以下讨论通知的章节中关于如何使得目标对象可以在通知体内访问到的部分。 任何一个只接受一个参数，且在运行时传入的参数实现了 Serializable 接口的连接点 （在Spring AOP中只是方法执行） args(java.io.Serializable)'args'在binding form中用的更多：- 请常见以下讨论通知的章节中关于如何使得方法参数可以在通知体内访问到的部分。 请注意在例子中给出的切入点不同于 execution(* *(java.io.Serializable))： args只有在动态运行时候传入参数是可序列化的（Serializable）才匹配，而execution 在传入参数的签名声明的类型实现了 Serializable 接口时候匹配。 有一个 @Transactional 注解的目标对象中的任意连接点（在Spring AOP中只是方法执行） @target(org.springframework.transaction.annotation.Transactional)'@target' 也可以在binding form中使用：请常见以下讨论通知的章节中关于如何使得annotation对象可以在通知体内访问到的部分。 任何一个目标对象声明的类型有一个 @Transactional 注解的连接点（在Spring AOP中只是方法执行） @within(org.springframework.transaction.annotation.Transactional)'@within'也可以在binding form中使用：- 请常见以下讨论通知的章节中关于如何使得annotation对象可以在通知体内访问到的部分。 任何一个执行的方法有一个 @Transactional annotation的连接点（在Spring AOP中只是方法执行） @annotation(org.springframework.transaction.annotation.Transactional)'@annotation' 也可以在binding form中使用：- 请常见以下讨论通知的章节中关于如何使得annotation对象可以在通知体内访问到的部分。 任何一个接受一个参数，并且传入的参数在运行时的类型实现了 @Classified annotation的连接点（在Spring AOP中只是方法执行） @args(com.xyz.security.Classified)'@args'也可以在binding form中使用：- 请常见以下讨论通知的章节中关于如何使得annotation对象可以在通知体内访问到的部分。 6.2.4. 声明通知 通知是跟一个切入点表达式关联起来的，并且在切入点匹配的方法执行之前或者之后或者之前和之后运行。 切入点表达式可能是指向已命名的切入点的简单引用或者是一个已经声明过的切入点表达式。 6.2.4.1. 前置通知（Before advice） 一个切面里使用 @Before 注解声明前置通知： import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.Before; @Aspect public class BeforeExample { @Before("com.xyz.myapp.SystemArchitecture.dataAccessOperation()") public void doAccessCheck() { // ... } }如果使用一个in-place 的切入点表达式，我们可以把上面的例子换个写法： import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.Before; @Aspect public class BeforeExample { @Before("execution(* com.xyz.myapp.dao.*.*(..))") public void doAccessCheck() { // ... } }6.2.4.2. 返回后通知（After returning advice） 返回后通知通常在一个匹配的方法返回的时候执行。使用 @AfterReturning 注解来声明： import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.AfterReturning; @Aspect public class AfterReturningExample { @AfterReturning("com.xyz.myapp.SystemArchitecture.dataAccessOperation()") public void doAccessCheck() { // ... } }说明：你可以在同一个切面里定义多个通知，或者其他成员。我们只是在展示如何定义一个简单的通知。这些例子主要的侧重点是正在讨论的问题。 有时候你需要在通知体内得到返回的值。你可以使用以 @AfterReturning 接口的形式来绑定返回值： import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.AfterReturning; @Aspect public class AfterReturningExample { @AfterReturning( pointcut="com.xyz.myapp.SystemArchitecture.dataAccessOperation()", returning="retVal") public void doAccessCheck(Object retVal) { // ... } }在 returning 属性中使用的名字必须对应于通知方法内的一个参数名。 当一个方法执行返回后，返回值作为相应的参数值传入通知方法。 一个 returning 子句也限制了只能匹配到返回指定类型值的方法。 （在本例子中，返回值是 Object 类，也就是说返回任意类型都会匹配） 6.2.4.3. 抛出后通知（After throwing advice） 抛出后通知在一个方法抛出异常后执行。使用 @AfterThrowing 注解来声明： import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.AfterThrowing; @Aspect public class AfterThrowingExample { @AfterThrowing("com.xyz.myapp.SystemArchitecture.dataAccessOperation()") public void doRecoveryActions() { // ... } }你通常会想要限制通知只在某种特殊的异常被抛出的时候匹配，你还希望可以在通知体内得到被抛出的异常。 使用 throwing 属性不光可以限制匹配的异常类型（如果你不想限制，请使用 Throwable 作为异常类型），还可以将抛出的异常绑定到通知的一个参数上。 import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.AfterThrowing; @Aspect public class AfterThrowingExample { @AfterThrowing( pointcut="com.xyz.myapp.SystemArchitecture.dataAccessOperation()", throwing="ex") public void doRecoveryActions(DataAccessException ex) { // ... } }在 throwing 属性中使用的名字必须与通知方法内的一个参数对应。 当一个方法因抛出一个异常而中止后，这个异常将会作为那个对应的参数送至通知方法。 throwing 子句也限制了只能匹配到抛出指定异常类型的方法（上面的示例为 DataAccessException）。 6.2.4.4. 后通知（After (finally) advice） 不论一个方法是如何结束的，在它结束后（finally）后通知（After (finally) advice）都会运行。 使用 @After 注解来声明。这个通知必须做好处理正常返回和异常返回两种情况。通常用来释放资源。 import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.After; @Aspect public class AfterFinallyExample { @After("com.xyz.myapp.SystemArchitecture.dataAccessOperation()") public void doReleaseLock() { // ... } }6.2.4.5. 环绕通知（Around Advice） 最后一种通知是环绕通知。环绕通知在一个方法执行之前和之后执行。 它使得通知有机会既在一个方法执行之前又在执行之后运行。并且，它可以决定这个方法在什么时候执行，如何执行，甚至是否执行。 环绕通知经常在在某线程安全的环境下，你需要在一个方法执行之前和之后共享某种状态的时候使用。 请尽量使用最简单的满足你需求的通知。（比如如果前置通知（before advice）也可以适用的情况下不要使用环绕通知）。 环绕通知使用 @Around 注解来声明。通知的第一个参数必须是 ProceedingJoinPoint 类型。 在通知体内，调用 ProceedingJoinPoint 的 proceed() 方法将会导致潜在的连接点方法执行。 proceed 方法也可能会被调用并且传入一个 Object[] 对象-该数组将作为方法执行时候的参数。 当传入一个 Object[] 对象的时候，处理的方法与通过AspectJ编译器处理环绕通知略有不同。 对于使用传统AspectJ语言写的环绕通知来说，传入参数的数量必须和传递给环绕通知的参数数量匹配（不是后台的连接点接受的参数数量），并且特定顺序的传入参数代替了将要绑定给连接点的原始值（如果你看不懂不用担心）。 Spring采用的方法更加简单并且更好得和他的基于代理（proxy-based），只匹配执行的语法相适用。 如果你适用AspectJ的编译器和编织器来编译为Spring而写的@AspectJ切面和处理参数，你只需要了解这一区别即可。 有一种方法可以让你写出100%兼容Spring AOP和AspectJ的，我们将会在后续的通知参数（advice parameters）的章节中讨论它。 import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.Around; import org.aspectj.lang.ProceedingJoinPoint; @Aspect public class AroundExample { @Around("com.xyz.myapp.SystemArchitecture.businessService()") public Object doBasicProfiling(ProceedingJoinPoint pjp) throws Throwable { // start stopwatch Object retVal = pjp.proceed(); // stop stopwatch return retVal; } }方法的调用者得到的返回值就是环绕通知返回的值。 例如：一个简单的缓存切面，如果缓存中有值，就返回该值，否则调用proceed()方法。 请注意proceed可能在通知体内部被调用一次，许多次，或者根本不被调用。 6.2.4.6. 通知参数（Advice parameters） Spring 2.0 提供了完整的通知类型 - 这意味着你可以在通知签名中声明所需的参数，（就像在以前的例子中我们看到的返回值和抛出异常一样）而不总是使用Object[]。 我们将会看到如何在通知体内访问参数和其他上下文相关的值。首先让我们看以下如何编写普通的通知以找出正在被通知的方法。 6.2.4.6.1. 访问当前的连接点 任何通知方法可以将第一个参数定义为 org.aspectj.lang.JoinPoint 类型 （环绕通知需要定义为 ProceedingJoinPoint 类型的， 它是 JoinPoint 的一个子类。） JoinPoint 接口提供了一系列有用的方法， 比如 getArgs()（返回方法参数）、getThis()（返回代理对象）、getTarget()（返回目标）、getSignature()（返回正在被通知的方法相关信息）和 toString()（打印出正在被通知的方法的有用信息）。 6.2.4.6.2. 传递参数给通知（Advice） 我们已经看到了如何绑定返回值或者异常（使用后置通知（after returning）和异常后通知（after throwing advice）。 为了可以在通知（adivce）体内访问参数，你可以使用 args 来绑定。 如果在一个参数表达式中应该使用类型名字的地方使用一个参数名字，那么当通知执行的时候对应的参数值将会被传递进来。 可能给出一个例子会更好理解。假使你想要通知（advise）接受某个Account对象作为第一个参数的DAO操作的执行，你想要在通知体内也能访问到account对象，你可以写如下的代码： @Before("com.xyz.myapp.SystemArchitecture.dataAccessOperation() &&" + "args(account,..)") public void validateAccount(Account account) { // ... }切入点表达式的 args(account,..) 部分有两个目的： 首先它保证了只会匹配那些接受至少一个参数的方法的执行，而且传入的参数必须是 Account 类型的实例， 其次它使得可以在通知体内通过 account 参数来访问那个account参数。 另外一个办法是定义一个切入点，这个切入点在匹配某个连接点的时候“提供”了一个Account对象， 然后直接从通知中访问那个命名的切入点。你可以这样写： @Pointcut("com.xyz.myapp.SystemArchitecture.dataAccessOperation() &&" + "args(account,..)") private void accountDataAccessOperation(Account account) {} @Before("accountDataAccessOperation(account)") public void validateAccount(Account account) { // .. }如果想要知道更详细的内容，请参阅 AspectJ 编程指南。 代理对象（this）、目标对象（target） 和注解（@within, @target, @annotation, @args）都可以用一种简单格式绑定。 以下的例子展示了如何使用 @Auditable 注解来匹配方法执行，并提取AuditCode。 首先是 @Auditable 注解的定义： @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) public @interface Auditable { AuditCode value(); } 然后是匹配 @Auditable 方法执行的通知： @Before("com.xyz.lib.Pointcuts.anyPublicMethod() && " + "@annotation(auditable)") public void audit(Auditable auditable) { AuditCode code = auditable.value(); // ... } 6.2.4.6.3. 决定参数名 绑定在通知上的参数依赖切入点表达式的匹配名，并借此在（通知（advice）和切入点（pointcut））的方法签名中声明参数名。 参数名 无法 通过Java反射来获取，所以Spring AOP使用如下的策略来决定参数名字： 如果参数名字已经被用户明确指定，则使用指定的参数名： 通知（advice）和切入点（pointcut）注解有一个额外的"argNames"属性，该属性用来指定所注解的方法的参数名 - 这些参数名在运行时是 可以 访问的。例子如下： @Before( value="com.xyz.lib.Pointcuts.anyPublicMethod() && " + "@annotation(auditable)", argNames="auditable") public void audit(Auditable auditable) { AuditCode code = auditable.value(); // ... } 如果一个@AspectJ切面已经被AspectJ编译器（ajc）编译过了，那么就不需要再添加 argNames 参数了，因为编译器会自动完成这一工作。 使用 'argNames' 属性有点不那么优雅，所以如果没有指定'argNames' 属性， Spring AOP 会寻找类的debug信息，并且尝试从本地变量表（local variable table）中来决定参数名字。 只要编译的时候使用了debug信息（至少要使用 '-g:vars' ），就可获得这些信息。 使用这个flag编译的结果是： (1)你的代码将能够更加容易的读懂（反向工程）， (2)生成的class文件会稍许大一些（不重要的）， (3)移除不被使用的本地变量的优化功能将会失效。 换句话说，你在使用这个flag的时候不会遇到任何困难。 如果不加上debug信息来编译的话，Spring AOP将会尝试推断参数的绑定。 （例如，要是只有一个变量被绑定到切入点表达式（pointcut expression）、通知方法（advice method）将会接受这个参数， 这是显而易见的）。 如果变量的绑定不明确，将会抛出一个 AmbiguousBindingException 异常。 如果以上所有策略都失败了，将会抛出一个 IllegalArgumentException 异常。 6.2.4.6.4. 处理参数 我们之前提过我们将会讨论如何编写一个 带参数的 的proceed()调用，使得不论在Spring AOP中还是在AspectJ都能正常工作。 解决方法是保证通知签名依次绑定方法参数。比如说： @Around("execution(List "com.xyz.myapp.SystemArchitecture.inDataAccessLayer() && " + "args(accountHolderNamePattern)") public Object preProcessQueryPattern(ProceedingJoinPoint pjp, String accountHolderNamePattern) throws Throwable { String newPattern = preProcess(accountHolderNamePattern); return pjp.proceed(new Object[] {newPattern}); } 大多数情况下你都会这样绑定（就像上面的例子那样）。 6.2.4.7. 通知（Advice）顺序 如果有多个通知想要在同一连接点运行会发生什么？Spring AOP 的执行通知的顺序跟AspectJ的一样。 在“进入”连接点的情况下，最高优先级的通知会先执行（所以上面给出的两个前置通知（before advice）中，优先级高的那个会先执行）。 在“退出”连接点的情况下，最高优先级的通知会最后执行。（所以上面给出的两个前置通知（before advice）中，优先级高的那个会第二个执行）。 对于定义在相同切面的通知，根据声明的顺序来确定执行顺序。比如下面这个切面： @Aspect public class AspectWithMultipleAdviceDeclarations { @Pointcut("execution(* foo(..))") public void fooExecution() {} @Before("fooExecution()") public void doBeforeOne() { // .. } @Before("fooExecution()") public void doBeforeTwo() { // .. } @AfterReturning("fooExecution()") public void doAfterOne() { // .. } @AfterReturning("fooExecution()") public void doAfterTwo() { //.. } }这样，假使对于任何一个名字为foo的方法的执行， doBeforeOne、doBeforeTwo、doAfterOne 和 doAfterTwo 通知方法都需要运行。 执行顺序将按照声明的顺序来确定。在这个例子中，执行的结果会是： doBeforeOne doBeforeTwo foo doAfterOne doAfterTwo 换言之，因为doBeforeOne先定义，它会先于doBeforeTwo执行，而doAfterTwo后于doAfterOne定义，所以它会在doAfterOne之后执行。 只需要记住通知是按照定义的顺序来执行的就可以了。 - 如果想要知道更加详细的内容，请参阅AspectJ编程指南。 当定义在 不同的 切面里的两个通知都需要在一个相同的连接点中运行，那么除非你指定，否则执行的顺序是未知的。 你可以通过指定优先级来控制执行顺序。在Spring中可以在切面类中实现 org.springframework.core.Ordered 接口做到这一点。 在两个切面中，Ordered.getValue() 方法返回值较低的那个有更高的优先级。 6.2.5. 引入（Introductions） 引入（Introductions）（在AspectJ中被称为inter-type声明）使得一个切面可以定义被通知对象实现一个给定的接口，并且可以代表那些对象提供具体实现。 使用 @DeclareParents注解来定义引入。这个注解被用来定义匹配的类型拥有一个新的父亲。 比如，给定一个接口 UsageTracked，然后接口的具体实现 DefaultUsageTracked 类， 接下来的切面声明了所有的service接口的实现都实现了 UsageTracked 接口。（比如为了通过JMX输出统计信息）。 @Aspect public class UsageTracking { @DeclareParents(value="com.xzy.myapp.service.*+", defaultImpl=DefaultUsageTracked.class) public static UsageTracked mixin; @Before("com.xyz.myapp.SystemArchitecture.businessService() &&" + "this(usageTracked)") public void recordUsage(UsageTracked usageTracked) { usageTracked.incrementUseCount(); } }实现的接口通过被注解的字段类型来决定。@DeclareParents 注解的 value 属性是一个AspectJ的类型模式：- 任何匹配类型的bean都会实现 UsageTracked 接口。 请注意，在上面的前置通知（before advice）的例子中，service beans 可以直接用作 UsageTracked 接口的实现。 如果需要编程式的来访问一个bean，你可以这样写： UsageTracked usageTracked = (UsageTracked) context.getBean("myService");6.2.6. 切面实例化模型 这是一个高级主题... 默认情况下，在application context中每一个切面都会有一个实例。 AspectJ 把这个叫做单个实例化模型（singleton instantiation model）。 也可以用其他的生命周期来定义切面：- Spring支持AspectJ的 perthis 和 pertarget 实例化模型 （现在还不支持percflow、percflowbelow 和 pertypewithin ）。 一个"perthis" 切面的定义：在 @Aspect 注解中指定perthis 子句。 让我们先来看一个例子，然后解释它是如何运作的： @Aspect("perthis(com.xyz.myapp.SystemArchitecture.businessService())") public class MyAspect { private int someState; @Before(com.xyz.myapp.SystemArchitecture.businessService()) public void recordServiceUsage() { // ... } }这个perthis子句的效果是每个独立的service对象执行时都会创建一个切面实例（切入点表达式所匹配的连接点上的每一个独立的对象都会绑定到'this'上）。 service对象的每个方法在第一次执行的时候创建切面实例。切面在service对象失效的同时失效。 在切面实例被创建前，所有的通知都不会被执行，一旦切面对象创建完成，定义的通知将会在匹配的连接点上执行，但是只有当service对象是和切面关联的才可以。 如果想要知道更多关于per-clauses的信息，请参阅 AspectJ 编程指南。 'pertarget'实例模型的跟“perthis”完全一样，只不过是为每个匹配于连接点的独立目标对象创建一个切面实例。 6.2.7. 例子 现在你已经看到了每个独立的部分是如何运作的了，是时候把他们放到一起做一些有用的事情了！ 因为乐观锁的关系，有时候business services可能会失败（有人甚至在一开始运行事务的时候就失败了）。如果重新尝试一下，很有可能就会成功。 对于business services来说，重试几次是很正常的（Idempotent操作不需要用户参与，否则会得出矛盾的结论） 我们可能需要透明的重试操作以避免让客户看见 OptimisticLockingFailureException 例外被抛出。 很明显，在一个横切多层的情况下，这是非常有必要的，因此通过切面来实现是很理想的。 因为我们想要重试操作，我们会需要使用到环绕通知，这样我们就可以多次调用proceed()方法。下面是简单的切面实现： @Aspect public class OptimisticOperationExecutor implements Ordered { private static final int DEFAULT_MAX_RETRIES = 2; private int maxRetries = DEFAULT_MAX_RETRIES; private int order = 1; public void setMaxRetries(int maxRetries) { this.maxRetries = maxRetries; } public int getOrder() { return this.order; } public void setOrder(int order) { this.order = order; } @Around("com.xyz.myapp.SystemArchitecture.businessService()") public Object doOptimisticOperation(ProceedingJoinPoint pjp) throws Throwable { int numAttempts = 0; OptimisticLockingFailureException lockFailureException; do { numAttempts++; try { return pjp.proceed(); } catch(OptimisticLockingFailureException ex) { lockFailureException = ex; } } while(numAttempts <= this.maxRetries); throw lockFailureException; } }请注意切面实现了 Ordered 接口，这样我们就可以把切面的优先级设定为高于事务通知（我们每次重试的时候都想要在一个全新的事务中进行）。 maxRetries 和 order 属性都可以在Spring中配置。 主要的动作在 doOptimisticOperation 这个环绕通知中发生。 请注意这个时候我们所有的 businessService() 方法都会使用这个重试策略。 我们首先会尝试处理，然后如果我们得到一个 OptimisticLockingFailureException 意外，我们只需要简单的重试，直到我们耗尽所有预设的重试次数。 对应的Spring配置如下： class="com.xyz.myapp.service.impl.OptimisticOperationExecutor"> 为了改进切面，使之仅仅重试idempotent操作，我们可以定义一个 Idempotent 注解： @Retention(RetentionPolicy.RUNTIME) public @interface Idempotent { // marker annotation }并且对service操作的实现进行注解。 这样如果你只希望改变切面使得idempotent的操作会尝试多次，你只需要改写切入点表达式，这样只有 @Idempotent 操作会匹配： @Around("com.xyz.myapp.SystemArchitecture.businessService() && " + "@annotation(com.xyz.myapp.service.Idempotent)") public Object doOptimisticOperation(ProceedingJoinPoint pjp) throws Throwable { ... }6.3. Schema-based AOP support 如果你无法使用Java 5，或者你比较喜欢使用XML格式，Spring2.0也提供了使用新的"aop"命名空间来定义一个切面。 和使用@AspectJ风格完全一样，切入点表达式和通知类型同样得到了支持，因此在这一节中我们将着重介绍新的 语法 和回顾前面我们所讨论的如何写一个切入点表达式和通知参数的绑定等等（Section 6.2, “@AspectJ支持”)。 使用本章所介绍的aop命名空间标签（aop namespace tag），你需要引入Appendix A, XML Schema-based configuration中提及的spring-aop schema。 参见Section A.2.6, “The aop schema”。 在Spring的配置文件中，所有的切面和通知器都必须定义在 6.3.1. 声明一个切面 有了schema的支持，切面就和常规的Java对象一样被定义成application context中的一个bean。 对象的字段和方法提供了状态和行为信息，XML文件则提供了切入点和通知信息。 切面使用 ... ... 切面的支持bean（上例中的"aBean"）可以象其他Spring bean一样被容器管理配置以及依赖注入。 6.3.2. 声明一个切入点 切入点可以在切面里面声明，这种情况下切入点只在切面内部可见。切入点也可以直接在 一个描述service层中表示所有service执行的切入点可以如下定义： expression="execution(* com.xyz.myapp.service.*.*(..))"/> 注意切入点表达式本身使用了 Section 6.2, “@AspectJ支持” 中描述的AspectJ 切入点表达式语言。 如果你在Java 5环境下使用基于schema的声明风格，可参考切入点表达式类型中定义的命名式切入点，不过这在JDK1.4及以下版本中是不被支持的（因为依赖于Java 5中的AspectJ反射API）。 所以在JDK 1.5中，上面的切入点的另外一种定义形式如下： expression="com.xyz.myapp.SystemArchitecture.businessService()"/> 假定你有 Section 6.2.3.3, “共享常见的切入点（pointcut）定义”中说描述的 SystemArchitecture 切面。 在切面里面声明一个切入点和声明一个顶级的切入点非常类似： expression="execution(* com.xyz.myapp.service.*.*(..))"/> ... 当需要连接子表达式的时候，'&&'在XML中用起来非常不方便，所以关键字'and', 'or' 和 'not'可以分别用来代替'&&', '||' 和 '!'。 注意这种方式定义的切入点通过XML id来查找，并且不能定义切入点参数。在基于schema的定义风格中命名切入点支持较之@AspectJ风格受到了很多的限制。 6.3.3. 声明通知 和@AspectJ风格一样，基于schema的风格也支持5种通知类型并且两者具有同样的语义。 6.3.3.1. 通知（Advice） Before通知在匹配方法执行前进入。在 pointcut-ref="dataAccessOperation" method="doAccessCheck"/> ... 这里 dataAccessOperation 是一个顶级（ pointcut="execution(* com.xyz.myapp.dao.*.*(..))" method="doAccessCheck"/> ... 我们已经在@AspectJ风格章节中讨论过了，使用命名切入点能够明显的提高代码的可读性。 Method属性标识了提供了通知的主体的方法（doAccessCheck）。这个方法必须定义在包含通知的切面元素所引用的bean中。 在一个数据访问操作执行之前（执行连接点和切入点表达式匹配），切面中的"doAccessCheck"会被调用。 6.3.3.2. 返回后通知（After returning advice） After returning通知在匹配的方法完全执行后运行。和Before通知一样，可以在 pointcut-ref="dataAccessOperation" method="doAccessCheck"/> ... 和@AspectJ风格一样，通知主体可以接收返回值。使用returning属性来指定接收返回值的参数名： pointcut-ref="dataAccessOperation" returning="retVal" method="doAccessCheck"/> ... doAccessCheck方法必须声明一个名字叫 retVal 的参数。 参数的类型强制匹配，和先前我们在@AfterReturning中讲到的一样。例如，方法签名可以这样声明： public void doAccessCheck(Object retVal) {...6.3.3.3. 抛出异常后通知（After throwing advice） After throwing通知在匹配方法抛出异常退出时执行。在 pointcut-ref="dataAccessOperation" method="doRecoveryActions"/> ... 和@AspectJ风格一样，可以从通知体中获取抛出的异常。 使用throwing属性来指定异常的名称，用这个名称来获取异常： pointcut-ref="dataAccessOperation" thowing="dataAccessEx" method="doRecoveryActions"/> ... doRecoveryActions方法必须声明一个名字为 dataAccessEx 的参数。 参数的类型强制匹配，和先前我们在@AfterThrowing中讲到的一样。例如：方法签名可以如下这般声明： public void doRecoveryActions(DataAccessException dataAccessEx) {...6.3.3.4. 后通知（After (finally) advice） After (finally)通知在匹配方法退出后执行。使用 after 元素来声明： pointcut-ref="dataAccessOperation" method="doReleaseLock"/> ... 6.3.3.5. 通知 Around通知是最后一种通知类型。Around通知在匹配方法运行期的“周围”执行。 它有机会在目标方法的前面和后面执行，并决定什么时候运行，怎么运行，甚至是否运行。 Around通知经常在需要在一个方法执行前或后共享状态信息，并且是线程安全的情况下使用（启动和停止一个计时器就是一个例子）。 注意选择能满足你需求的最简单的通知类型（i.e.如果简单的before通知就能做的事情绝对不要使用around通知）。 Around通知使用 aop:around 元素来声明。 通知方法的第一个参数的类型必须是 ProceedingJoinPoint 类型。 在通知的主体中，调用 ProceedingJoinPoint的proceed() 方法来执行真正的方法。 proceed 方法也可能会被调用并且传入一个 Object[] 对象 - 该数组将作为方法执行时候的参数。 参见 Section 6.2.4.5, “环绕通知（Around Advice）” 中提到的一些注意点。 pointcut-ref="businessService" method="doBasicProfiling"/> ... doBasicProfiling 通知的实现和@AspectJ中的例子完全一样（当然要去掉注解）： public Object doBasicProfiling(ProceedingJoinPoint pjp) throws Throwable { // start stopwatch Object retVal = pjp.proceed(); // stop stopwatch return retVal; }6.3.3.6. 通知参数 Schema-based声明风格和@AspectJ支持一样，支持通知的全名形式 - 通过通知方法参数名字来匹配切入点参数。 参见 Section 6.2.4.6, “通知参数（Advice parameters）” 获取详细信息。 如果你希望显式指定通知方法的参数名（而不是依靠先前提及的侦测策略），可以通过 arg-names 属性来实现。示例如下： pointcut="com.xyz.lib.Pointcuts.anyPublicMethod() and @annotation(auditable)" method="audit" arg-names="auditable"/>The arg-names attribute accepts a comma-delimited list of parameter names. arg-names属性接受由逗号分割的参数名列表。 6.3.3.7. 通知顺序 当同一个切入点（执行方法）上有多个通知需要执行时，执行顺序规则在 Section 6.2.4.7, “通知（Advice）顺序” 已经提及了。 切面的优先级通过切面的支持bean是否实现了Ordered接口来决定。 6.3.4. 引入 Intrduction （在AspectJ中成为inter-type声明）允许一个切面声明一个通知对象实现指定接口，并且提供了一个接口实现类来代表这些对象。 在 aop:aspect 内部使用 aop:declare-parents 元素定义Introduction。 该元素用于用来声明所匹配的类型有了一个新的父类型（所以有了这个名字）。 例如，给定接口 UsageTracked，以及这个接口的一个实现类 DefaultUsageTracked， 下面声明的切面所有实现service接口的类同时实现 UsageTracked 接口。（比如为了通过JMX暴露statistics。） types-matching="com.xzy.myapp.service.*+", implement-interface="UsageTracked" default-impl="com.xyz.myapp.service.tracking.DefaultUsageTracked"/> pointcut="com.xyz.myapp.SystemArchitecture.businessService() and this(usageTracked)" method="recordUsage"/> The class backing the usageTracking bean would contain the method: usageTracking bean的支持类可以包含下面的方法： public void (UsageTracked usageTracked) { usageTracked.incrementUseCount(); }欲实现的接口由 implement-interface 属性来指定。 types-matching 属性的值是一个AspectJ类型模式：- 任何匹配类型的bean会实现 UsageTracked 接口。 注意在Before通知的例子中，srevice bean可以用作 UsageTracked 接口的实现。 如果编程形式访问一个bean，你可以这样来写： UsageTracked usageTracked = (UsageTracked) context.getBean("myService");6.3.5. 切面实例化模型 Schema-defined切面仅支持一种实例化模型就是singlton模型。其他的实例化模型或许在未来版本中将得到支持。 6.3.6. Advisors "advisors"这个概念来自Spring1.2对AOP的支持，在AspectJ中是没有等价的概念。 advisor就像一个小的自包含的切面，这个切面只有一个通知。 切面自身通过一个bean表示，并且必须实现一个通知接口， 在 Section 7.3.2, “Spring里的通知类型” 中我们会讨论相应的接口。Advisors可以很好的利用AspectJ切入点表达式。 Spring 2.0 通过 expression="execution(* com.xyz.myapp.service.*.*(..))"/> pointcut-ref="businessService" advice-ref="tx-advice"/> 和在上面使用的 pointcut-ref 属性一样，你还可以使用 pointcut 属性来定义一个内联的切入点表达式。 为了定义一个advisord的优先级以便让通知可以有序，使用 order 属性来定义 advisor的值 Ordered 。 6.3.7. 例子 让我们来看看在 Section 6.2.7, “例子” 提过乐观锁失败重试的例子，如果使用schema对这个例子进行重写是什么效果。 因为乐观锁的关系，有时候business services可能会失败（有人甚至在一开始运行事务的时候就失败了）。 如果重新尝试一下，很有可能就会成功。对于business services来说，重试几次是很正常的（Idempotent操作不需要用户参与，否则会得出矛盾的结论） 我们可能需要透明的重试操作以避免让客户看见 OptimisticLockingFailureException 例外被抛出。 很明显，在一个横切多层的情况下，这是非常有必要的，因此通过切面来实现是很理想的。 因为我们想要重试操作，我们会需要使用到环绕通知，这样我们就可以多次调用proceed()方法。 下面是简单的切面实现（只是一个schema支持的普通Java 类）： public class OptimisticOperationExecutor implements Ordered { private static final int DEFAULT_MAX_RETRIES = 2; private int maxRetries = DEFAULT_MAX_RETRIES; private int order = 1; public void setMaxRetries(int maxRetries) { this.maxRetries = maxRetries; } public int getOrder() { return this.order; } public void setOrder(int order) { this.order = order; } public Object doOptimisticOperation(ProceedingJoinPoint pjp) throws Throwable { int numAttempts = 0; OptimisticLockingFailureException lockFailureException; do { numAttempts++; try { return pjp.proceed(); } catch(OptimisticLockingFailureException ex) { lockFailureException = ex; } } while(numAttempts <= this.maxRetries); throw lockFailureException; } }请注意切面实现了 Ordered 接口，这样我们就可以把切面的优先级设定为高于事务通知（我们每次重试的时候都想要在一个全新的事务中进行）。 maxRetries 和 order 属性都可以在Spring中配置。 主要的动作在 doOptimisticOperation 这个环绕通知中发生。 请注意这个时候我们所有的 businessService() 方法都会使用这个重试策略。 我们首先会尝试处理，然后如果我们得到一个 OptimisticLockingFailureException 异常，我们只需要简单的重试，直到我们耗尽所有预设的重试次数。 这个类跟我们在@AspectJ的例子中使用的是相同的，只是没有使用注解。 对应的Spring配置如下： expression="execution(* com.xyz.myapp.service.*.*(..))"/> pointcut-ref="idempotentOperation" method="doOptimisticOperation"/> class="com.xyz.myapp.service.impl.OptimisticOperationExecutor"> 请注意我们现在假设所有的bussiness services都是idempotent。如果不是这样，我们可以改写切面，加上 Idempotent 注解，让它只调用idempotent： @Retention(RetentionPolicy.RUNTIME) public @interface Idempotent { // marker annotation }并且对service操作的实现进行注解。这样如果你只希望改变切面使得idempotent的操作会尝试多次，你只需要改写切入点表达式，这样只有 @Idempotent 操作会匹配： expression="execution(* com.xyz.myapp.service.*.*(..)) and @annotation(com.xyz.myapp.service.Idempotent)"/>6.4. 混合切面类型 我们完全可以混合使用以下几种风格的切面定义：使用自动代理的@AspectJ 风格的切面，schema-defined 6.5. 代理机制 Spring AOP部分使用JDK动态代理或者CGLIB来为目标对象创建代理。（建议尽量使用JDK的动态代理） 如果被代理的目标对象实现了至少一个接口，则会使用JDK动态代理。所有该目标类型实现的接口都将被代理。若该目标对象没有实现任何接口，则创建一个CGLIB代理。 如果你希望强制使用CGLIB代理，（例如：希望代理目标对象的所有方法，而不只是实现自接口的方法）那也可以。但是需要考虑以下问题: 无法通知（advise）Final 方法，因为他们不能被覆写。 你需要将CGLIB 2二进制发行包放在classpath下面，与之相较JDK本身就提供了动态代理 强制使用CGLIB代理需要将 ... 请注意这个属性的设置仅对 每一个 当需要使用CGLIB代理和@AspectJ自动代理支持，请按照如下的方式设置 除了在配置文件中使用 类 org.springframework.aop.aspectj.annotation.AspectJProxyFactory 可以为@AspectJ切面的目标对象创建一个代理。该类的基本用法非常简单，示例如下。请参看Javadoc获取更详细的信息。 // create a factory that can generate a proxy for the given target object AspectJProxyFactory factory = new AspectJProxyFactory(targetObject); // add an aspect, the class must be an @AspectJ aspect // you can call this as many times as you need with different aspects factory.addAspect(SecurityManager.class); // you can also add existing aspect instances, the type of the object // supplied must be an @AspectJ aspect factory.addAspect(usageTracker); // now get the proxy object... MyInterfaceType proxy = factory.getProxy();6.7. 在Spring应用中使用AspectJ 到目前为止本章讨论的一直是纯Spring AOP。 在这一节里面我们将介绍如何使用AspectJ compiler/weaver来代替Spring AOP或者作为它的补充，因为有些时候Spring AOP单独提供的功能也许并不能满足你的需要。 Spring提供了一个小巧的AspectJ aspect library （你可以在程序发行版本中单独使用 spring-aspects.jar 文件，并将其加入到classpath下以使用其中的切面）。 Section 6.7.1, “在Spring中使用AspectJ来为domain object进行依赖注入” 和 Section 6.7.2, “Spring中其他的AspectJ切面” 讨论了该库和如何使用该库。 Section 6.7.3, “使用Spring IoC来配置AspectJ的切面” 讨论了如何对通过AspectJ compiler织入的AspectJ切面进行依赖注入。 最后Section 6.7.4, “在Spring应用中使用AspectJ Load-time weaving（LTW）”介绍了使用AspectJ的Spring应用程序如何装载期织入（load-time weaving）。 6.7.1. 在Spring中使用AspectJ来为domain object进行依赖注入 Spring容器对application context中定义的bean进行实例化和配置。 同样也可以通过bean factory来为一个已经存在且已经定义为spring bean的对象应用所包含的配置信息。 spring-aspects.jar中包含了一个annotation-driven的切面，提供了能为任何对象进行依赖注入的能力。 这样的支持旨在为 脱离容器管理 创建的对象进行依赖注入。 Domain object经常处于这样的情形：它们可能是通过 new 操作符创建的对象， 也可能是ORM工具查询数据库的返回结果对象。 包 org.springframework.orm.hibernate.support 中的类 DependencyInjectionInterceptorFactoryBean 可以让Spring为Hibernate创建并且配置prototype类型的domain object（使用自动装配或者确切命名的bean原型定义）。 当然，拦截器不支持配置你编程方式创建的对象而非检索数据库返回的对象。 其他framework也会提供类似的技术。仍是那句话，Be Pragramatic选择能满足你需求的方法中最简单的那个。 请注意前面提及的类 没有 随Spring发行包一起发布。 如果你希望使用该类，需要从Spring CVS Respository上下载并且自行编译。 你可以在Spring CVS respository下的 'sandbox' 目录下找到该文件。 @Configurable 注解标记了一个类可以通过Spring-driven方式来配置。 在最简单的情况下，我们只把它当作标记注解： package com.xyz.myapp.domain; import org.springframework.beans.factory.annotation; @Configurable public class Account { ... 当只是简单地作为一个标记接口来使用的时候，Spring将采用和该已注解的类型（比如Account类）全名 （com.xyz.myapp.domain.Account）一致的bean原型定义来配置一个新实例。 由于一个bean默认的名字就是它的全名，所以一个比较方便的办法就是省略定义中的id属性： singleton="false"> ... 如果你希望明确的指定bean原型定义的名字，你可以在注解中直接定义： package com.xyz.myapp.domain; import org.springframework.beans.factory.annotation; @Configurable("account") public class Account { ... Spring会查找名字为"account"的bean定义，并使用它作为原型定义来配置一个新的Account对象。 你也可以使用自动装配来避免手工指定原型定义的名字。 只要设置 @Configurable 注解中的autowire属性就可以让Spring来自动装配了： @Configurable(autowire=Autowire.BY_TYPE) 或者 @Configurable(autowire=Autowire.BY_NAME，这样就可以按类型或者按名字自动装配了。 最后，你可以设置 dependencyCheck 属性，通过设置，Spring对新创建和配置的对象的对象引用进行校验 （例如：@Configurable(autowire=Autowire.BY_NAME,dependencyCheck=true) ）。 如果这个属性被设为true，Spring会在配置结束后校验除了primitives和collections类型的所有的属性是否都被赋值了。 仅仅使用注解并没有做任何事情。但当注解存在时，spring-aspects.jar中的 AnnotationBeanConfigurerAspect 就起作用了。 实质上切面做了这些：当初始化一个有 @Configurable 注解的新对象时，Spring按照注解中的属性来配置这个新创建的对象。 要实现上述的操作，已注解的类型必须由AspectJ weaver来织入 - 你可以使用一个 build-time ant/maven任务来完成 （参见AspectJ Development Environment Guide） 或者使用load-time weaving（参见 Section 6.7.4, “在Spring应用中使用AspectJ Load-time weaving（LTW）”）。 类 AnnotationBeanConfigurerAspect 本身也需要Spring来配置（获得bean factory的引用，使用bean factory配置新的对象）。 为此Spring AOP命名空间定义了一个非常方便的标签。如下所示，可以很简单的在application context配置文件包含这个标签中。 class="org.springframework.beans.factory.aspectj.AnnotationBeanConfigurerAspect" factory-method="aspectOf"/>在切面配置完成 之前 创建的@Configurable对象实例会导致在log中留下一个warning，并且任何对于该对象的配置都不会生效。 举一个例子，一个Spring管理配置的bean在被Spring初始化的时候创建了一个domain object。 对于这样的情况，你需要定义bean属性中的"depends-on"属性来手动指定该bean依赖于configuration切面。 class="com.xzy.myapp.service.MyService" depends-on="org.springframework.beans.factory.aspectj.AnnotationBeanConfigurerAspect"> ... 6.7.1.1. @Configurable object的单元测试 提供 @Configurable 支持的一个目的就是使得domain object的单元测试可以独立进行，不需要通过硬编码查找各种倚赖关系。 如果 @Configurable 类型没有通过AspectJ织入， 则在单元测试过程中注解不会起到任何作用，测试中你可以简单的为对象的mock或者stub属性赋值，并且和正常情况一样的去使用该对象。 如果 @Configurable 类型通过AspectJ织入， 我们依然可以脱离容器进行单元测试，不过每次创建一个新的 @Configurable 对象时都会看到一个warning标示该对象不受Spring管理配置。 6.7.1.2. 多application context情况下的处理 AnnotationBeanConfigurerAspect 通过一个AspectJ singleton切面来实现对 @Configurable 的支持。 一个singleton切面的作用域和一个静态变量的作用域是一样的，例如，对于每一个classloader有一个切面来定义类型。 这就意味着如果你在一个classloader层次结构中定义了多个application context的时候就需要考虑在哪里定义 考虑一下典型的Spring web项目，一般都是由一个父application context定义大部分business service和所需要的其他资源，然后每一个servlet拥有一个子application context定义。 所有这些context共存于同一个classloader hierarchy下，因此对于全体context，AnnotationBeanConfigurerAspect 仅可以维护一个引用。 在这样的情况下，我们推荐在父application context中定义 当在一个容器中部署多个web-app的时候，请确保每一个web-application使用自己的classloader来加载spring-aspects.jar中的类（例如将spring-aspects.jar放在WEB-INF/lib目录下）。 如果spring-aspects.jar被放在了容器的classpath下（因此也被父classloader加载），则所有的web application将共享一个aspect实例，这可能并不是你所想要的。 6.7.2. Spring中其他的AspectJ切面 除了 @Configurable 支持，spring-aspects.jar包含了一个AspectJ切面可以用来为那些使用了 @Transactional annotation 的类型和方法驱动Spring事务管理（参见 Chapter 9, 事务管理）。 提供这个的主要目的是有些用户希望脱离Spring容器使用Spring的事务管理。 对于AspectJ程序员，希望使用Spring管理配置和事务管理支持，不过他们不想（或者不能）使用注解，spring-aspects.jar也包含了一些抽象切面供你继承来提供你自己的切入点定义。 参见 AbstractBeanConfigurerAspect 和 AbstractTransactionAspect 的Javadoc获取更多信息。 作为一个例子，下面的代码片断展示了如何编写一个切面，然后通过bean原型定义中和类全名匹配的来配置domian object中所有的实例： public aspect DomainObjectConfiguration extends AbstractBeanConfigurerAspect { public DomainObjectConfiguration() { setBeanWiringInfoResolver(new ClassNameBeanWiringInfoResolver()); } /** * The creation of a new bean (any object in the domain model) */ protected pointcut beanCreation(Object beanInstance) : initialization(new(..)) && SystemArchitecture.inDomainModel() && this(beanInstance); }6.7.3. 使用Spring IoC来配置AspectJ的切面 当在Spring application中使用AspectJ的时候，很自然的会想到用Spring来管理这些切面。 AspectJ runtime自身负责切面的创建，这意味着通过Spring来管理AspectJ 创建切面依赖于切面所使用的AspectJ instantiation model(per-clause)。 大多数AspectJ切面都是 singleton 切面。 管理这些切面非常容易，和通常一样创建一个bean定义引用该切面类型就可以了，并且在bean定义中包含 factory-method="aspectOf" 这个属性。 这确保Spring从AspectJ获取切面实例而不是尝试自己去创建该实例。示例如下： factory-method="aspectOf"> 对于non-singleton的切面，最简单的配置管理方法是定义一个bean原型定义并且使用@Configurable支持，这样就可以在切面被AspectJ runtime创建后管理它们。 如果你希望一些@AspectJ切面使用AspectJ来织入（例如使用load-time织入domain object） 和另一些@AspectJ切面使用Spring AOP，而这些切面都是由Spring来管理的，那你就需要告诉Spring AOP @AspectJ自动代理支持那些切面需要被自动代理。 你可以通过在 6.7.4. 在Spring应用中使用AspectJ Load-time weaving（LTW） Load-time weaving（LTW）指的是在虚拟机载入字节码文件时动态织入AspectJ切面。 关于LTW的详细信息，请查看 LTW section of the AspectJ Development Environment Guide。 在这里我们重点来看一下Java 5环境下Spring应用如何配置LTW。 LTW需要定义一个 aop.xml，并将其置于META-INF目录。 AspectJ会自动查找所有可见的classpath下的META-INF/aop.xml文件，并且通过定义内容的合集来配置自身。 一个基本的META-INF/aop.xml文件应该如下所示：
"-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd"> 'include'的内容告诉AspectJ那些类型需要被纳入织入过程。使用包名前缀并加上"..*"（表示该子包中的所有类型）是一个不错的默认设定。 使用include元素是非常重要的，不然AspectJ会查找每一个应用里面用到的类型（包括Spring的库和其它许多相关库）。通常你并不希望织入这些类型并且不愿意承担AspectJ尝试去匹配的开销。 希望在日志中记录LTW的活动，请添加如下选项：
"-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd"> options="-showWeaveInfo, -XmessageHandlerClass:org.springframework.aop.aspectj.AspectJWeaverMessageHandler"> 最后，如果希望精确的控制使用哪些切面，可以使用 aspects。 默认情况下所有定义的切面都将被织入（spring-aspects.jar包含了META-INF/aop.xml，定义了配置管理和事务管理切面）。 如果你在使用spring-aspects.jar，但是只希望使用配制管理切面而不需要事务管理的话，你可以像下面那样定义：
"-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd"> options="-showWeaveInfo,-XmessageHandlerClass:org.springframework.aop.aspectj.AspectJWeaverMessageHandler"> 在Java 5平台下，LTW可以通过虚拟机的参数来启用。 -javaagent: 更多关于AspectJ的信息可以查看 AspectJ home page。 Eclipse AspectJ by Adrian Colyer et. al. (Addison-Wesley, 2005)全面介绍并提供了AspectJ语言参考。 AspectJ in Action by Ramnivas Laddad (Manning, 2003)是一本非常出色介绍AOP的书籍；全书着重介绍了AspectJ，但也对一些通用的AOP场景进行了比较深入的研究。 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/SmartTony/archive/2008/01/23/2061942.aspx