spring aop配置文档部分翻译

欢迎转载交流： http://www.cnblogs.com/shizhongtao/p/3476973.html

下面的文字来自官方文档的翻译，具体事例以后奉上。

Advisors

"advisors"这个概念来自Spring1.2对AOP的支持，在AspectJ中是没有等价的概念。 advisor就像一个小的自包含的切面，这个切面只有一个通知。 切面自身通过一个bean表示，并且必须实现一个通知接口。Advisors可以很好的利用AspectJ切入点表达式。

Spring 2.0 通过 <aop:advisor> 元素来支持advisor 概念。 你将会发现它大多数情况下会结合transactional advice使用，<aop:advisor>在Spring 2.0中有自己的命名空间。格式如下：

<aop:config>
<aop:pointcut id="businessService"
expression="execution(* com.xyz.myapp.service.*.*(..))"/> <aop:advisor
pointcut-ref="businessService"
advice-ref="tx-advice"/>
</aop:config> <tx:advice id="tx-advice">
<tx:attributes>
<tx:method name="*" propagation="REQUIRED"/>
</tx:attributes>
</tx:advice>

就想使用 pointcut-ref 属性一样，你还可以使用 pointcut 属性来定义一个内联的切入点表达式。

你可以使用order属性来定义advice的先后顺序。

示例

让我们来看看在 Section 9.2.7, “Example”提过并发锁失败重试的例子，使用schema进行重写是什么效果。

由于并发问题（例如：死锁失败），业务逻辑服务层（business services）有时候会执行失败。 如果重新尝试一下，他下次执行可能就会成功。对于business services来说，失败后重试是很正常的（Idempotent操作不需要用户参与，否则会得出矛盾的结论） 我们可能需要透明的重试操作以避免让客户看见 PessimisticLockingFailureException 例外被抛出。 这就要求在一个跨域多各服务层进行操作，因此通过切面编程是很理想的实现。

因为我们想要进行重试操作，我们会需要使用到around advice，这样我们就可以多次调用proceed()方法来实现重试操作。 下面是简单的切面实现（一个schema支持的普通Java 类）：

public class ConcurrentOperationExecutor 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 doConcurrentOperation(ProceedingJoinPoint pjp) throws Throwable {
int numAttempts = 0;
PessimisticLockingFailureException lockFailureException;
do {
numAttempts++;
try {
return pjp.proceed();
}
catch(PessimisticLockingFailureException ex) {
lockFailureException = ex;
}
}
while(numAttempts <= this.maxRetries);
throw lockFailureException;
}}

请注意上面的切面类实现了 Ordered 接口，这样我们就可以把切面的优先级设定为高于事务通知（我们每次重试的时候都想要在一个新的事务中进行）。 maxRetries 和 order 属性都在Spring中配置。主要实现过程发生在当（around advice） doConcurrentOperation方法调用的时候。 请注意这个时候我们所有的 businessService() 方法都会使用这个重试策略。 我们会尝试执行时，如果我们得到一个 PessimisticLockingFailureException 异常，程序就会帮助我们简单的重试，直到耗尽所有预设的重试次数。

除了没有使用注解（annotation），这个类与我们使用@AspectJ 时候是一样的。

对应的spring配置如下：

<aop:config> <aop:aspect id="concurrentOperationRetry" ref="concurrentOperationExecutor"> <aop:pointcut id="idempotentOperation"
expression="execution(* com.xyz.myapp.service.*.*(..))"/> <aop:around
pointcut-ref="idempotentOperation"
method="doConcurrentOperation"/> </aop:aspect> </aop:config> <bean id="concurrentOperationExecutor"
class="com.xyz.myapp.service.impl.ConcurrentOperationExecutor">
<property name="maxRetries" value="3"/>
<property name="order" value="100"/>
</bean>

请注意我们现在假设所有的业务操作都是idempotent。如果不是这样，我们可以改写切面方法，加上 Idempotent 注解，让它只调用idempotent：

@Retention(RetentionPolicy.RUNTIME)
public @interface Idempotent {
// marker annotation
}

对于使用annotation方式对service操作进行注解。这样你希望改变切面使得idempotent的操作会尝试多次，你只需要改写切入点表达式来使 @Idempotent 操作匹配：

<aop:pointcut id="idempotentOperation"
expression="execution(* com.xyz.myapp.service.*.*(..)) and
@annotation(com.xyz.myapp.service.Idempotent)"/>

9.4选择AOP声明风格的

当你确定切面是实现一个给定需求的最佳方法时，那么如何选择是使用Spring AOP还是AspectJ，以及确定使用Aspect语言（代码）风格还是@AspectJ声明风格又或者spring XML风格？这个决定会受到多个因素的影响，比如应用的需求、 开发工具和小组对AOP的熟练程度。

9.4.1 Spring AOP还是完全用AspectJ？

用最简单的步骤来工作。Spring AOP比完全使用AspectJ更加简单，因为它不需要引入AspectJ的编译器到你开发和构建过程中。 如果你只需要在Spring bean上进行操作，那么Spring AOP是合适的选择。如果你需要advice 的对象没有交给spring容器管理，那么你需要使用AspectJ。如果你想advice简单的方法执行之外的连接点（如：字段get或set的连接点等等）， 也需要使用AspectJ。

当使用AspectJ时，你可以选择使用AspectJ语法（也称为“代码风格”）或@AspectJ注解风格。需要指出的是，如果你没有使用Java 5+，你就必须选择使用Aspectj语法了。 如果切面在你的设计中扮演一个很重要（或者比例很大）的角色，那么你就可以在Eclipse中使用AspectJ Development Tools (AJDT)插件；或者在你的应用中只有很少的切面编程，你或许应该考虑使用@AspectJ风格，并且在你的构建脚本中增加切面编译的部分。

9.4.2 Spring AOP中使用@AspectJ还是XML？

如果你使用Spring AOP，那么你可以选择@AspectJ或者XML风格。总的来说，如果你使用Java 5+， 建议使用@AspectJ风格。如果你不是运行在Java 5上，XML风格是最佳选择。

XML风格对现有的Spring用户来说更加习惯。它可以使用在任何JDK版本中（参考pointcut表达式内部的命名连接点，虽然它也需要Java 5+） 并且通过纯粹的POJO来支持。当使用AOP作为工具来配置企业服务时（一个好的例子是，你可能想单独更改pointcut表达式，不管她是不是你配置的一部分）XML会是一个很好的选择。对于XML风格，从你的配置中可以清晰的表明在系统中存在那些切面。

XML风格有两个缺点。第一是它不能完全将需求实现的地方封装到一个位置。DRY原则中说系统中的每一项知识都必须具有单一、无歧义、权威的表示。 当使用XML风格时，如何实现一个需求被分割到支撑类的声明中以及XML配置文件中。当使用@AspectJ风格时就只有一个单独的模块 -切面- 信息被封装了起来。 第二是XML风格同@AspectJ风格所能表达的内容相比有更多的限制：仅仅支持单例模式的切面实例模型，并且不能在XML中组合命名连接点的声明。 例如，在@AspectJ风格中我们可以编写这样的内容：

@Pointcut(execution(* get*()))
public void propertyAccess() {} @Pointcut(execution(org.xyz.Account+ *(..))
public void operationReturningAnAccount() {} @Pointcut(propertyAccess() && operationReturningAnAccount())
public void accountPropertyAccess() {}

在xml风格中，我能声明开始的两个连接点，

<aop:pointcut id="propertyAccess"
expression="execution(* get*())"/> <aop:pointcut id="operationReturningAnAccount"
expression="execution(org.xyz.Account+ *(..))"/>

但你不能通过组合来实现"accountPropertyAccess"的pointcut申明。
@AspectJ风格支持附加的实例模型以及更丰富的连接点组合。它具有将将切面保持为一个模块单元的优点。
还有一个优点就是Spring AOP和AspectJ两者都支持@AspectJ切面风格， 所以如果稍后你认为你需要AspectJ
的能力去实现附加的需求，那么你非常容易将spring aop转换成基于AspectJ的项目。总而言之，spring团队更喜欢@AspectJ风格只要你有切面
去做超出简单的“配置”企业服务之外的事情。

9.5混合切面类型

……