Uploaded image for project: 'Spring Roo'
  1. Spring Roo
  2. ROO-1925

AbstractItdMetadataProvider should permit more flexible class-level downstream dependency resolution

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: 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.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: