RE: [Springframework-developer] AOP Alliance API changes

[<jue...@we...>]

I've reworked TransactionAttributeSourceEditor: It now matches _all_ =
methods of a given name if overloaded, not just the first one, and =
supports "xxx*" for method names. The need arose from a concrete =
application at werk3AT that uses declarative transactions now.

BTW, I've considered using regular expressions for pattern matching, but =
I consider "java\.lang\.object\.notify.*" somewhat unintuitive. The =
"xxx*" way should just be a simple alternative to specifying each =
individual method. And switching to regex would even make individual =
specifications harder and less intuitive, as dots would have to be =
escaped.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, July 23, 2003 9:17 PM
To: spr...@li...
Subject: [Springframework-developer] AOP Alliance API changes
Importance: High


All,

You'll recall that AOP Alliance and AOPI merged a month or so ago. The
result has been some changes to the old AOP Alliance interfaces, which
Spring 0.9 implements.

These changes don't really affect how things work, just package and =
method
naming.

I've just checked in the necessary changes (and current AOP Alliance =
jar).

This will break any interceptors you have. However, it's easy to make =
the
changes. In nearly all cases, it will involve 2 easy steps:

1. imports org.aopalliance.* -> org.aopalliance.intercept.*

2. MethodInvocation.invokeNext() -> proceed(). This is more in line with =
AOP
terminology, and still intelligible to us J2EE folk.

I was able to migrate my code in projects using Spring AOP in minutes,
including my interceptors. (The changes shouldn't affect you if you =
haven't
written your own interceptors).

**** NB: Clean before rebuilding your local copy of Spring.

I really like the new AOP Alliance APIs. I think they're very powerful =
and
quite elegant.

As an added bonus, I've checked in a regular expression pointcut:
com.interface21.aop.framework.RegexpMethodPointcut

Set a Perl5 reg exp (such as ".*set.*") as the "pattern" property and an
interceptor ref as the "interceptor" property and drop the regexp =
pointcut
name in your interceptor names for your ProxyFactoryBean and you're all =
set.

This depends on Jakarta ORO. I chose this because Struts uses it and it
seems to work well. If anyone objects strongly to this choice of reg exp
(obviously we can't go to 1.4 yet) please let me know.

I've also recently introduced a distinction between static and dynamic
pointcuts. Static pointcuts depend on the method invoked and perhaps
attributes; dynamic pointcuts also get to see the arguments.

The WildcardAttributeRegistry is a move towards a better attributes
solution, although I'm still keen to pursue source-level attributes. I =
would
love a volunteer to help drive the attributes side of things as my time =
is
limited.

Regards,
Rod




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer