Github user neykov commented on a diff in the pull request:
https://github.com/apache/incubator-brooklyn/pull/1017#discussion_r44542412
--- Diff:
api/src/main/java/org/apache/brooklyn/api/typereg/BrooklynTypeRegistry.java ---
@@ -45,24 +45,25 @@
/** @return The item matching the given given
* {@link RegisteredType#getSymbolicName() symbolicName}
* and optionally {@link RegisteredType#getVersion()},
- * filtered for the optionally supplied {@link
RegisteredTypeConstraint},
+ * filtered for the optionally supplied {@link
RegisteredTypeLoadingContext},
* taking the best version if the version is null or a default marker,
* returning null if no matches are found. */
- RegisteredType get(String symbolicName, String version, @Nullable
RegisteredTypeConstraint constraint);
- /** as {@link #get(String, String, RegisteredTypeConstraint)} with no
constraints */
+ RegisteredType get(String symbolicName, String version, @Nullable
RegisteredTypeLoadingContext constraint);
+ /** as {@link #get(String, String, RegisteredTypeLoadingContext)} with
no constraints */
RegisteredType get(String symbolicName, String version);
- /** as {@link #get(String, String, RegisteredTypeConstraint)} but
allows <code>"name:version"</code>
+ /** as {@link #get(String, String, RegisteredTypeLoadingContext)} but
allows <code>"name:version"</code>
* (the {@link RegisteredType#getId()}) in addition to the unversioned
name,
* using a default marker if no version can be inferred */
- RegisteredType get(String symbolicNameWithOptionalVersion, @Nullable
RegisteredTypeConstraint constraint);
- /** as {@link #get(String, RegisteredTypeConstraint)} but with no
constraints */
+ RegisteredType get(String symbolicNameWithOptionalVersion, @Nullable
RegisteredTypeLoadingContext constraint);
--- End diff --
It's not clear from the javadoc what does the `constraint` filter on `get`
methods. Do we allow conflicting types in the registry - for example a catalog
item and a bean with the same `symbolicName` (in which case `version` is not
enough of a discriminator)?
* if yes, then shouldn't the return type be a collection for the case
where the `constraint` wasn't strict enough?
* if no, then why have a constraint at all here, I see it's not used yet
in the implementation?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
