Spring Roo
  1. Spring Roo
  2. ROO-1390

Increase the management of ItdSourceFileComposer management and DefaultItdTypeDetailsBuilder

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 1.1.0.RELEASE
    • Component/s: @ CORE
    • Labels:
      None
    • Environment:
      SUN JDK 1.5.0_07
      Ubuntu 10.04
      Eclipse 3.5.1

      Description

      Hi!

      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:

      declare @method: !@AnnotatedMethod * TestRequirements.*(..) : @NewAnnotatedMethod(new = true);
      

      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.
      This could improve the management of AspectJ generated files by an Addon an make more use of its capabilities.

      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.
      Thank you!

        Activity

        Hide
        Ben Alex added a comment -

        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.

        Show
        Ben Alex added a comment - 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.

          People

          • Assignee:
            Ben Alex
            Reporter:
            Ricardo García
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: