|
From: Rod J. <rod...@in...> - 2003-11-30 17:32:27
|
All, I've made some further AOP changes, partly to allow for further CGLIB optimization, but principally to allow for a cleaner approach to pooling etc. The InvokerInterceptor is now gone. The old approach of the terminal interceptor invoking the target object has been replaced by this behaviour in the MethodInvocation itself. Of course other "terminal" invokers such as the EJB invokers will continue to work just fine as they don't call proceed. Other MethodInvocation implementations--CGLIB etc.--can have their own invocation behavior, for greater efficiency. (We don't want to end up calling Method.invoke with CGLIB.) Instead, there's a new interface: org.springframework.aop.TargetSource will identifies the "this" part of the joinpoint. (Of course this kind of thing isn't "classic" AOP and I don't think it can be done with AspectJ. But it's useful.) Normally the implementation is SingletonTargetSource, which caches a target. However, PrototypeInvokerInterceptor etc. are now in the aop.target package as PrototypeTargetSource, ThreadLocalTargetSource etc. A TargetSource or target can be used as the final name in an interceptor chain, as a target could formerly, so there shouldn't be that much impact on code. The only effect on your code should be: - if you use the PrototypeInvokerInterceptor, PoolingInvokerInterceptor or ThreadLocalInvokerInterceptor, in which case you need to move that bean definition to the corresponding TargetSource, which will be configured similarly. - if you created AOP proxies programmatically using an InvokerInterceptor. This is no longer necessary. - if you've subclassed or otherwise depended on the internals of some of the AOP classes. Note that it's no longer necessary to add an InvokerInterceptor as the last advisor when creating a proxy programmatically: a nice feature. So for: ProxyFactory p = new ProxyFactory(target); p.addInterceptor(0, new DebugInterceptor()); Can omit the index (0) in the second line. In the second line now we can add interceptors in order without bothering about the index (although this version will still work). Because there's no InvokerInterceptor, there are no longer any special requirements for the last interceptor. Regards, Rod |
|
From: Rod J. <rod...@in...> - 2004-02-22 10:09:03
|
All, I've just committed some changes to the Advisor hierarchy, to get rid of the parallel hierarchy between Advisors and Advices, which was bothering me. Now instead of having a hierarchy of Advisors, Advisor has a getAdvice() method that returns Object. It can't be more strongly typed because of AOP Alliance compliance. Originally I think I wanted to get away from such weak typing, but I'm just not happy with the old parallel class hierarchices. There are no longer specific Advisor subclasses, like DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor. An Advisor has a pointcut associated with it or not. There are quite a few fewer classes in the new approach (-17 I think). And it's more flexible, as DefaultPointcutAdvisor can be reused for any advice type. The impact on user code should be quite small. If you've extended one of those advisors, extend the appropriate generic PointcutAdvisor subclass. RegExpMethodPointcutAdvisor now replaces the old Around advice pointcut advisor. The changes make it possible to reuse the regexp pointcut advisor (or other pointcut advisor subclasses) for any kind of advice. Because this is a public API change, I think we need to consider going RC2, instead of straight to 1.0 now. I was strongly in favour of going straight to 1.0, but there have also been some other public API changes (notably in JDBC) as well as the new Quartz functionality, so I vote for a quick release of RC2 (early this week) and a goal of 1.0 2 weeks after that, with NO more changes except bug fixes. Regards, Rod |
|
From: Colin S. <col...@ex...> - 2004-02-22 13:27:13
|
+1 on the RC2 Rod Johnson wrote: >All, > >I've just committed some changes to the Advisor hierarchy, to get rid of the >parallel hierarchy between Advisors and Advices, which was bothering me. > >Now instead of having a hierarchy of Advisors, Advisor has a getAdvice() >method that returns Object. It can't be more strongly typed because of AOP >Alliance compliance. Originally I think I wanted to get away from such weak >typing, but I'm just not happy with the old parallel class hierarchices. >There are no longer specific Advisor subclasses, like >DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor. An Advisor >has a pointcut associated with it or not. > >There are quite a few fewer classes in the new approach (-17 I think). And >it's more flexible, as DefaultPointcutAdvisor can be reused for any advice >type. > >The impact on user code should be quite small. If you've extended one of >those advisors, extend the appropriate generic PointcutAdvisor subclass. >RegExpMethodPointcutAdvisor now replaces the old Around advice pointcut >advisor. > >The changes make it possible to reuse the regexp pointcut advisor (or other >pointcut advisor subclasses) for any kind of advice. > >Because this is a public API change, I think we need to consider going RC2, >instead of straight to 1.0 now. I was strongly in favour of going straight >to 1.0, but there have also been some other public API changes (notably in >JDBC) as well as the new Quartz functionality, so I vote for a quick release >of RC2 (early this week) and a goal of 1.0 2 weeks after that, with NO more >changes except bug fixes. > >Regards, >Rod > > |
|
From: <tri...@tr...> - 2004-02-22 14:03:41
|
> Because this is a public API change, I think we need to consider going RC2, > instead of straight to 1.0 now. I was strongly in favour of going straight > to 1.0, but there have also been some other public API changes (notably in > JDBC) as well as the new Quartz functionality, so I vote for a quick release > of RC2 (early this week) and a goal of 1.0 2 weeks after that, +1 > with NO more > changes except bug fixes. > :-) Thomas |
