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中有自己的命名空间。格式如下:
1 <aop:config> 2 <aop:pointcut id="businessService" 3 expression="execution(* com.xyz.myapp.service.*.*(..))"/> 4 5 <aop:advisor 6 pointcut-ref="businessService" 7 advice-ref="tx-advice"/> 8 </aop:config> 9 10 <tx:advice id="tx-advice"> 11 <tx:attributes> 12 <tx:method name="*" propagation="REQUIRED"/> 13 </tx:attributes> 14 </tx:advice>就想使用 pointcut-ref 属性一样,你还可以使用 pointcut 属性来定义一个内联的切入点表达式。
你可以使用order属性来定义advice的先后顺序。
示例
让我们来看看在 Section 9.2.7, “Example”提过并发锁失败重试的例子,使用schema进行重写是什么效果。
由于并发问题(例如:死锁失败),业务逻辑服务层(business services)有时候会执行失败。 如果重新尝试一下,他下次执行可能就会成功。对于business services来说,失败后重试是很正常的(Idempotent操作不需要用户参与,否则会得出矛盾的结论) 我们可能需要透明的重试操作以避免让客户看见 PessimisticLockingFailureException 例外被抛出。 这就要求在一个跨域多各服务层进行操作,因此通过切面编程是很理想的实现。
因为我们想要进行重试操作,我们会需要使用到around advice,这样我们就可以多次调用proceed()方法来实现重试操作。 下面是简单的切面实现(一个schema支持的普通Java 类):
View Codepublic 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配置如下:
1 <aop:config> 2 3 <aop:aspect id="concurrentOperationRetry" ref="concurrentOperationExecutor"> 4 5 <aop:pointcut id="idempotentOperation" 6 expression="execution(* com.xyz.myapp.service.*.*(..))"/> 7 8 <aop:around 9 pointcut-ref="idempotentOperation" 10 method="doConcurrentOperation"/> 11 12 </aop:aspect> 13 14 </aop:config> 15 16 <bean id="concurrentOperationExecutor" 17 class="com.xyz.myapp.service.impl.ConcurrentOperationExecutor"> 18 <property name="maxRetries" value="3"/> 19 <property name="order" value="100"/> 20 </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风格中我们可以编写这样的内容:
1 @Pointcut(execution(* get*())) 2 public void propertyAccess() {} 3 4 @Pointcut(execution(org.xyz.Account+ *(..)) 5 public void operationReturningAnAccount() {} 6 7 @Pointcut(propertyAccess() && operationReturningAnAccount()) 8 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混合切面类型
……