|
[
Permlink
| « Hide
]
Adrian Colyer added a comment - 31/May/06 05:46 AM
deferred to 2.1
Guys, how much effort would it be to get a first prototype of this working? I've currently scheduled it for 2.1 M2 in late May - is that feasible?
Juergen Based on Adrian's notes, it shouldn't take that long. We should be able to get this implemented in time for 2.1M2.
I think we should add a big warning in the documentation of this feature, because it is proprietary to Spring AOP. Using the bean() pointcut pattern, you don't have a clear upgrade path to AspectJ any more. Also, it gives Spring bean names a meaning, which is something we generally warn against.
Note that I'm not against this feature, just wondering about the consequences. Arjen, it should be possible to implement the same syntax in the AspectJ itself...
Arjen,
Re warning: I agree that we need to have documentation warning about this pointcut extension, especially given that this is the first time AspectJ syntax supported by proxy-weaver won't be a strict subset of the AspectJ language. Re Upgrade path: There won't be a simple upgrade path to the AspectJ weaver. However, given several semantic differences between the two weaving technologies, upgrade will almost guaranteed to pose some challenges. Further, I can imagine that with some cookbook style changes, a similar functionality can be implemented with aspects woven using the AspectJ weaver. Re bean naming: Giving "business meaning" to Spring beans is generally we warn against. However, in this case, the names will have only technical meaning, therefore programmers will be controlling both the naming the bean part and consuming that name through the pointcut. ---- Eugene, Implementing the same syntax in AspectJ will be neither possible nor desirable as AspectJ doesn't know anything about the Spring world. Ramnivas, I think there is still some possibility to implement it in AspectJ. More over @Configurable annotation is already used to wire things up between Spring and plain classes.
Eugene,
May be this is some confusion of terminologies. Please describe what you mean by "implement it in AspectJ". I was simply referring to the migration path from Spring's proxy-based AOP to compile-time AJ support for bean() pcd.
Anyways, one way to implement it is to implicitly wire up BeanFactoryAware interface into the class for the named bean, so bean factory will be set by Spring. Then bean factory can be used at the run-time to check if object instance is matching declared named bean. That would of course require some knowledge about spring config at the compile time, but it probably not necessary with @AspectJ variant. Okay, I see what you mean now. The idea you describe is what I had in mind when I commented "Further, I can imagine that with some cookbook style changes, a similar functionality can be implemented with aspects woven using the AspectJ weaver. "
That said, just to be explicitly clear, the bean() PCD cannot be supported in AspectJ itself i.e. the aspects that use the bean() PCD cannot be successfully compiled using the AspectJ compiler or woven by the AspectJ weaver. The best thing that can be done is offer ways for users to implement the same functionally (by the way of perhaps showing a few examples), but not the syntax. Right, bean() pcd is not supported by the current AspectJ compiler, but it should be technically possible to extend AJ compiler to support such pcd. :-)
Core implementation complete and committed.
There is still a problem with using the bean() PCD in a reference pointcut, which needs to be reviewed for a potential issue in the current AspectJ implementation. What's the definition of NamePattern?
Where does the code live in CVS? The code in CVS is at:
* spring/src/org/springframework/aop/aspectj/AspectJExpressionPointcut.java (version 1.30) * spring/src/org/springframework/aop/aspectj/BeanNamePointcutDesignatorHandler.java (version 1.1) * spring/src/org/springframework/aop/aspectj/ProxyCreationContext.java (version 1.1) * spring/src/org/springframework/aop/aspectj/autoproxy/AspectJAwareAdvisorAutoProxyCreator.java (version 1.4) * spring/tiger/src/org/springframework/aop/aspectj/annotation/AspectJProxyFactory.java (version 1.6) * spring/test/org/springframework/aop/aspectj/BeanNamePointcutMatchingTests.java (version 1.1) * spring/test/org/springframework/aop/aspectj/BeanNamePointcutTests.java (version 1.1) * spring/test/org/springframework/aop/aspectj/bean-name-pointcut-tests.xml (version 1.1) * spring/tiger/test/org/springframework/aop/aspectj/BeanNamePointcutAtAspectTests.java (version 1.1) * spring/tiger/test/org/springframework/aop/aspectj/bean-name-pointcut-atAspect-tests.xml (version 1.1) The NamePattern used is the AspectJ's name pattern. Please see tests for more details. Will bean() match on generated bean names as well?
At the moment inner beans, and beans produced by the various namespace handler parsers/decorator will easily generate names that could match a less-carefully written name pattern. It would be nice if bean() only applied on "real" names, but I guess that would require a huge effort. So, any comments on the request to make bean() only match "real" names, and not generated ones? To me that would seem a bit more reliable.
I am looking into ways to make bean() match only user specified names. As it stands now, matching uses bean name -- real or generated.
Fixed the inner bean matching problem. The bean() PCD now never matches an inner bean.
Another proposal would be to exclude beans that are coming from custom namespaces.
Is there a way to reliably distinguish such beans? It seems AbstractBeanDefinition#isSynthetic is not used is a consistent way, although I might be misinterpreting its semantics.. Resolving this bugs.
New bugs Note the current limitation of the bean() PCD ( Due to an AspectJ bug, you cannot use the bean() PCD in a reference pointcut in @AspectJ syntax (XML-based aspects do not exhibit this bug). The 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 <meta>, 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.1? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Support bean(NamePattern) pcd
