spring aop配置文档部分翻译

时间:2023-11-28 23:28:26

欢迎转载交流: 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 接口,这样我们就可以把切面的优先级设定为高于事务通知(我们每次重试的时候都想要在一个新的事务中进行)。 maxRetriesorder 属性都在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混合切面类型

……