Spring Roo
  1. Spring Roo
  2. ROO-1925

AbstractItdMetadataProvider should permit more flexible class-level downstream dependency resolution

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 1.1.0.RELEASE
    • Fix Version/s: 1.1.1.RELEASE
    • Component/s: @ CORE
    • Labels:
      None

      Description

      Currently AbstractItdMetadataProvider supports dependency registrations where the downstream is:

      • "Instance-specific", meaning the target downstream MID for a notification is known in advance and presented as part of the metadata notification from the MetadataDependencyRegistry.
      • A "null" downstream dependency can be presented via a generic listener and handled by the new ROO-1882 mechanism. However this approach means all metadata events in the system pass through the MetadataProvider, which is inefficient if only a particular subset of known-in-advance metadata notifications are desired.
      • A "class-level" downstream dependency (of the MetadataProvider.getProvidesType()) if and only if the upstream dependency is a PhysicalTypeIdentifier notification. In this case the AbstractItdMetadataProvider unwraps the upstream notification's MID (ie a PhysicalTypeIdentifier) and converts it into a local MetadataProvider instance-specific MID.

      Sometimes it is desirable to "listen" for all metadata notifications of a particular type, just as we do for PhysicalTypeIdentifier. If every metadata notification will pass to an instance-specific MID, the first approach listed above works fine. If the upstream metadata is a PhysicalTypeIdentifier, the last approach above will accommodate it. However, it is not presently handled if the upstream is a non-PhysicalTypeIdentifier and the downstream is not instance-specific.

      We should add a new method to AbstractItdMetadataProvider that subclasses can override to resolve a class-level downstream into an instance-specific downstream if the third scenario above is occurring. The AbstractItdMetadataProvider code should handle the PhysicalTypeIdentifier use case and be available for super() calls if desired.

        Activity

        Hide
        Ben Alex added a comment -

        Added AbstractItdMetadataProvider.resolveDownstreamDependencyIdentifier(String upstreamDependency):String() (appropriated JavaDoced) in bf013d8f38fd93253fdddc4ea060c2ddae757d31.

        Show
        Ben Alex added a comment - Added AbstractItdMetadataProvider.resolveDownstreamDependencyIdentifier(String upstreamDependency):String() (appropriated JavaDoced) in bf013d8f38fd93253fdddc4ea060c2ddae757d31.

          People

          • Assignee:
            Ben Alex
            Reporter:
            Ben Alex
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: