The first case is a known bug that is being fixed in the upcoming AspectJ (http://jira.springframework.org/browse/SPR-3688). The second case, however, should work fine. Please file a bug if that is not the case.

-Ramnivas

To restrict advice to specific methods in specific beans, you combine a bean() pointcut with an execution() pointcut. Something like: bean(*Repository) && execution(* store*(..)).

-Ramnivas

Am I missing something?
Regards,
Ashish Jamthe

Try to use it with 2.5, but failed.

Assume could not define it as an aspectj pointcut, like
@Pointcut("bean(*Service)"), which will be reported as 'wildcard is not allowed' error.

Use it directly in advice, like
@Before("bean(*Service)"), turns out that the beans are not be AOPed.

Many thanks,

Eric

Thanks for your kind words about 2.5! I'm glad the new pointcut designator made it in: it's a cool feature and a nice synergy between the AspectJ and Spring models.

I think the key thing is not how much you do, but how well you do it. We remain true to our belief that everything we do has to deliver real technical benefit.

Having said that, however, I'm not sure we have much core competence in brewing, but I would sure like a Spring Wheat Beer…

Rgds
Rod

Interface21 has been very successful and is getting a lot of cash stuffed in their pockets right now. This is usually the time where the open-source product group goes mad with power, and starts marketing their own Spring-branded portal, ESB, and soft drink.

Looking at the feature list for Spring 2.5, it seems this hasn't happened. You guys haven't lost site of what your core competencies are, and have kept your attention there.[/quote]

Corby,

Glad that you are excited about the feature.

Look at breadth of the portfolio (Spring Framework, Spring .NET, Acegi, Spring WebServices, Spring WebFlow, Spring Batch, Pitchfork, Spring IDE, AspectJ, Spring OSGi, Spring LDAP, Spring Rich Client plus all of the stuff that isn't even public yet) and one could argue (and many have before) that we've been "mad with power" for quite sometime.

By the way, a Spring Wheat Beer or Spring Coffee Bean is far more likely than a Spring Cola, and we've had the idea for both long before we ever even thought about raising money.

Neelan

I certainly see that in future we may support a metadata-based pointcut for beans, say, @bean(, ). The problem is that using metadata with beans is just not a common practice. Ideally (in my opinion, at least), pointcuts should leverage what's already out there — class names, package structure, method signature, bean names, any metadata etc. If and when typical Spring applications start using bean metadata for purposes other than solely to be picked up by a pointcut, that will be the ideal time to add such a pointcut. Alternatively, we could be convinced (through use cases) how such a pointcut may simplify Spring applications.

The whole data vs. metadata topic is quite fascinating to me (see, for example, a two-part series I wrote a while back http://www.ibm.com/developerworks/java/library/j-aopwork3 and http://www.ibm.com/developerworks/java/library/j-aopwork4) and is something I feel strongly about. So I am ready to be convinced of addition of such a pointcut if it adds significant value. As it stands now, the named-based bean() pointcut is useful and in future we may add additional metadata-based pointcuts. This isn't much different than how AspectJ progressed.

Indeed the support for bean() pointcut in Spring IDE is very useful (sorry that I forgot to mention in the original post).

-Ramnivas

More information is available from http://springide.org/blog/2007/06/27/spring-ide-20-is-final/