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-1882mechanism. 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.