Github user ahgittin commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/70#discussion_r56633005
--- Diff:
api/src/main/java/org/apache/brooklyn/api/location/LocationRegistry.java ---
@@ -86,25 +94,62 @@
public boolean canMaybeResolve(String spec);
/** As {@link #resolve(String, Boolean, Map)}, but unwrapped
- * @throws NoSuchElementException if the spec cannot be resolved */
+ * @throws NoSuchElementException if the spec cannot be resolved
+ * @deprecated since 0.9.0 use {@link #getLocationSpec(String, Map)}
and then manage it as needed*/
+ @SuppressWarnings("rawtypes")
+ @Deprecated
public Location resolve(String spec, @Nullable Map locationFlags);
/**
- * As {@link #resolve(String)} but takes collections (of strings or
locations)
+ * As {@link #getLocationManaged(String)} but takes collections (of
strings or locations)
* <p>
* Expects a collection of elements being individual location spec
strings or locations,
* and returns a list of resolved (newly created and managed)
locations.
* <p>
* From 0.7.0 this no longer flattens lists (nested lists are
disallowed)
* or parses comma-separated elements (they are resolved as-is)
- */
+ * @deprecated since 0.9.0 use {@link
#getListOfLocationsManaged(Object)} */
+ @Deprecated
public List<Location> resolve(Iterable<?> spec);
/** Takes a string, interpreted as a comma-separated (or JSON style,
when you need internal double quotes or commas) list;
* or a list, passed to {@link #resolve(Iterable)}; or null/empty
(empty list),
- * and returns a list of resolved (created and managed) locations */
+ * and returns a list of resolved (created and managed) locations
+ * @deprecated since 0.9.0 use {@link
#getListOfLocationsManaged(Object)} */
+ @Deprecated
public List<Location> resolveList(Object specList);
+
+ /** Create a {@link LocationSpec} representing the given spec string
such as a named location
+ * or using a resolver prefix such as jclouds:aws-ec2.
+ * This can then be inspected, assigned to an {@link EntitySpec},
+ * or passed to {@link LocationManager#createLocation(LocationSpec)}
to create directly.
+ * (For that last case, common in tests, see {@link
#getLocationManaged(String)}.) */
+ public Maybe<LocationSpec<? extends Location>> getLocationSpec(String
spec);
+ /** As {@link #getLocationSpec(String)} but also setting the given
flags configured on the resulting spec. */
+ public Maybe<LocationSpec<? extends Location>> getLocationSpec(String
spec, Map<?,?> locationFlags);
+
+ /** As {@link #getLocationSpec(String)} where the caller has a {@link
LocationDefinition}. */
+ public Maybe<LocationSpec<? extends Location>>
getLocationSpec(LocationDefinition ld);
+ /** As {@link #getLocationSpec(String,Map)} where the caller has a
{@link LocationDefinition}. */
+ public Maybe<LocationSpec<? extends Location>>
getLocationSpec(LocationDefinition ld, Map<?,?> locationFlags);
+ /** A combination of {@link #getLocationSpec(String)} then {@link
LocationManager#createLocation(LocationSpec)},
+ * mainly for use in tests or specialised situations where a managed
location is needed directly.
+ * The caller is responsible for ensuring that the resulting {@link
Location}
+ * is cleaned up, ie removed from management via {@link
LocationManager#unmanage(Location)} directly or linking it to
+ * an {@link Entity} or another {@link Location} which will unmanage
it. */
+ public Location getLocationManaged(String spec);
--- End diff --
I thought so too at first but it is otherwise an ugly syntax to create
location from spec string (get spec object then pass to location manager) and
hundreds of places it should sit. I think longer term this method should sit
on the `TypeRegistry` as a convenience so defer that sweeping change.
---
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.
---
