Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Resource Resolver 1.6.0
-
None
Description
The current ResourceResolver#map methods return a single "path mapped from the (resource) path". However, it is possible than a given path can be mapped to multiple others while using features such as sling:alias and sling:vanityUrl.
In order to support that scenario, it is require to implement new maps method for ResourceResolver which returns a collection of "resolved path". This collection must contain the resources mapped through /etc/map, sling:alias and sling:vanityUrl.
The current API suggests to implement a second method to be consistent/symmetric with the existing map operations
@Nonnull java.util.Collection<java.lang.String> maps(@Nonnull java.lang.String resourcePath)
@Nonnull java.util.Collection<java.lang.String> maps(@Nonnull javax.servlet.http.HttpServletRequest request, @Nonnull java.lang.String resourcePath)
Attachments
Attachments
Issue Links
- relates to
-
SLING-11757 resource resolver: pathless URL in vanity path causes NPE in ResourceMapperImpl.apply()
- Closed
-
SLING-5773 NonExistingResource.getParent() must consider the resource resolver mapping
- Resolved
- links to
How will the client code select which path to use if you resolve to multiple candidates and return just their paths?
We probably need to see the whole picture of how you intend to use this to understand better, but if there are multiple candidates I think the resolver should provide values such as which one are favorites, or why each candidate is present in the result set, to be able to make a sensible decision about which path to actually use.
Or maybe it's just a question of assigning priorities to the various mapping mechanisms, if their precedence is currently undefined (I' don't know if that's the case).