[ROO-1390] Increase the management of ItdSourceFileComposer management and DefaultItdTypeDetailsBuilder Created: 14/Sep/10 Updated: 19/Oct/10 Resolved: 19/Oct/10
|Reporter:||Ricardo García||Assignee:||Ben Alex|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
SUN JDK 1.5.0_07
I want to generate a Metadata (AspectJ) with a rule in wich all methods that aren't annotated with defined annotation (@AnnotatedMethod) in a class (TestRequirements) asign an especific annotation (@NewAnnotatedMethod(new = true)). This is the AspectJ declaration:
The DefaultItdTypeDetailsBuilder class provides some methods to update a method, method annotations, types annotation, etc... to generate AspectJ but there is no method defined to create a custom rule like this in ROO. Then ItdSourceFileComposermanagement generates the AspectJ file with this information.
These are two posts in AspectJ bugzilla that we post related to this topic which can be useful to implement a solution to manage with ROO that will be released in 1.6.10 version:
Declare annotation to a method param:
Declare annotation - augmentation/overriding and precedence:
I think this could be useful to Addon development.
|Comment by Ben Alex [ 19/Oct/10 ]|
The ItdTypeDetails infrastructure is intended to represent the introduction of simple members into a target type based on the target type being the "governor". It is beyond the intended scope of ItdTypeDetails to support pointcut expressions that may result in a given Roo-produced ITD introducing a member to multiple types via a single declaration. If this were simply a matter of ITD source code emission convenience we could perhaps allow it, but the broader issue is infrastructure such as MemberDetailsScanner is frequently used to locate all members introduced into a type and this relies on the ItdTypeDetails knowing which members are actually introduced. If pointcut expressions were supported by ItdTypeDetails, it would be necessary to invoke the AspectJ matcher API to determine the joinpoints which match the pointcut. This would add significant extra complexity to Roo (plus a new Roo tool dependency) while also creating a performance bottleneck given the frequency that MemberDetailsScanner-type operations are performed.
There are two alternatives available. The preferred approach is an add-on perform its own scan and use the standard ItdTypeDetailsBuilder infrastructure to introduce the new member, such as via the addMethodAnnotation(..) method. This will mean compatibility with other add-ons and totally efficient MemberDetailsScanner-type operations. The other alternative is nothing stops an add-on writing their own .aj files out to disk, so they could emit their own ITD source file containing the required expression. The downside is this will not be parsed by Roo and therefore other add-ons will never be aware of the contents. For this reason I prefer the first approach.
I am closing this as won't fix due to the technical consequences of supporting it. Hope the above makes sense.