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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to