The new bean() pointcut
Spring 2.5 features a new pointcut designator — bean() that allows selecting join points in beans with a matching name pattern. Now it is possible to use the auto-proxy mechanism along with Spring-AspectJ integration to select a specific bean even when there are more than one beans of a type. Earlier, you could use BeanNameAutoProxyCreator to achieve a similar result; however, that mechanism didn't work with Schema-style or @AspectJ aspects.
Besides selecting a specific bean, this pointcut designator offers two interesting ways to select beans if you follow an appropriate naming convention:
- Selecting a vertical slice of beans: If you follow a convention where bean names include a string indicating their role from the business perspective, a bean() pointcut can select beans based on their business role. For example, you may use the bean(account*) pointcut to select all accounting-related beans such as accountRepository, accountService, and accountController if bean names start with a string representing their business functionality.
- Selecting a horizontal slice of beans: If you follow a convention where bean names include a string indicating their role from the architectural perspective, a bean() pointcut can select beans based on their architectural role. For example, you can use bean(*Repository) to select all repository beans if bean names end with a string representing their architectural role. Without the bean() pointcut, you had to rely on the package structure or type-based pointcuts, which can be sometimes a bit too restrictive.
Figure 1: Selecting horizontal and vertical slices of beans based on their names using bean() pointcuts
This pointcut represents a Spring-specific extension to the AspectJ pointcut expression language and as such is useful only in a Spring-based application. The name-pattern follows the AspectJ matching rules for a name pattern with '*' being the only allowed wildcard. Here is a table showing a few example pointcuts and beans selected by them.
| Pointcut | Join points selected in |
|---|---|
| bean(accountRepository) | The bean named "accountRepository" |
| !bean(accountRepository) | Any bean except the "accountRepository" bean |
| bean(*) | Any bean |
| bean(account*) | Any bean with name starting in "account" |
| bean(*Repository) | Any bean with name ending in "Repository" |
| bean(accounting/showaccount) | The bean named accounting/showaccount (designating, say, a controller handling that URL) |
| bean(accounting/*) | Any bean whose name starts with "accounting/" (designating, say, any controller handling accounting-related URLs) |
| bean(accounting/*/edit) | Any bean whose name starts with "accounting/" and ends with "/edit" (designating, say, any controller handling the edit operation functionality related to accounting) |
| bean(*dataSource) || bean(*DataSource) | Any bean whose name ends with either "dataSource" or "DataSource" |
| bean(service:name=monitoring) | The bean named "service:name=monitoring" |
Similar Posts
- Configuration Simplifications in Spring 3.0
- AOP Context Binding With Named Pointcuts
- Annotation-Driven Dependency Injection in Spring 2.1
- Spring Java Configuration – What's New in M3
- Customizing Annotation Configuration and Component Detection in Spring 2.1
Taras Tielkes says:
Added on September 24th, 2007 at 12:50 pmThe use of bean name *patterns* gives implicit meaning to bean name suffixes and/or prefixes.
In essence, such an usage pattern gives additional metadata semantics to bean names.
There's already a metadata mechanism available in Spring: the , represented by org.springframework.core.AttributeAccessor.
A custom pcd could match metadata tuples. It seems to me that this would be a much cleaner separation of the concerns "naming" and "classifying".
With the current state of bean() – AspectJ bugs, qualification of "real" names by looking for a '#' character, etc – perhaps it would be a good idea to reconsider this feature for 2.5?
Taras Tielkes says:
Added on September 24th, 2007 at 12:51 pmAbove comment refers to the [meta] element – that part got eaten by the comment parser.
Corby Page says:
Added on September 24th, 2007 at 1:52 pmI am super excited about this feature. It is exactly the sort of focused, powerful enhancement that I want to see in the framework.
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.
Christian Dupuis says:
Added on September 25th, 2007 at 1:18 amWhat Ramnivas didn't mentioned: the bean() pointcut is already supported by Spring IDE since version 2.0.
More information is available from http://springide.org/blog/2007/06/27/spring-ide-20-is-final/
Ramnivas Laddad (blog author) says:
Added on September 25th, 2007 at 1:53 pmChristian,
Indeed the support for bean() pointcut in Spring IDE is very useful (sorry that I forgot to mention in the original post).
-Ramnivas
Ramnivas Laddad (blog author) says:
Added on September 25th, 2007 at 2:12 pmTaras,
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.
Neelan Choksi says:
Added on September 28th, 2007 at 1:49 pm[quote comment="51264"]I am super excited about this feature. It is exactly the sort of focused, powerful enhancement that I want to see in the framework.
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
Rod Johnson (blog author) says:
Added on September 30th, 2007 at 2:54 pmCorby
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
Eric says:
Added on December 3rd, 2007 at 7:50 amIs the bean pointcut developed in 2.5?
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
Ashish Jamthe says:
Added on January 17th, 2008 at 11:12 pmUsing this feature I can restrict the Aspect to certain beans. I did not understand, How do I restrict the aspect to certain functions of certain beans? For example, all the store* methods of all the repositories (the beans which end in *Repository)
Am I missing something?
Regards,
Ashish Jamthe
Ramnivas Laddad (blog author) says:
Added on January 18th, 2008 at 6:19 amAshish,
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
Ramnivas Laddad (blog author) says:
Added on January 18th, 2008 at 6:22 amEric,
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