[
https://issues.apache.org/jira/browse/SLING-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-198:
------------------------------------
Component/s: (was: Scripting)
ServletResolver
Description:
As a result of defining a virtual resource tree (SLING-197) we have a need to
modify the ResourceResolver API in two respects:
(1) Add ResourceResolver.resolve(String absPath)
This method behaves exactly as ResourceResolver.resolve(HttpServletRequest)
except, that the latter method may make use of additional request properties,
such as request headers or parameters while the resolve(String) method only has
the string to work on.
Currently the resolve(HttpServletRequest) method does nothing more than use the
HttpServletRequest.getPathInfo() to resolve the resource, thus both
implementations would actually be equivalent.
The absPath argument is an absolute path. Resolution fails for relative paths.
(2) Support relative paths in ResourceResolver.getResource(String path)
Currently this method is defined to throw a SlingException if the path is
relative. This should be changed such that the ResourceResolver applies some
search path logic to find a resource with the given relative path
The search path logic is comparable to how *nix systems use the PATH
environment variable.
This method may then be used by multiple users such as Servlet/Script
resolution.
(3) Add ResourceResolver.map(Resource) method
This method applies the reverse mappings of the ResourceResolver.resolve(String
absPath) method to return a path suitable for both resolver() methods. This
allows for the creation of link paths for resources.
was:
As a result of defining a virtual resource tree (SLING-197) we have a need to
codify in the API two additional interfaces:
(1) PathResolver
Given a relative path a path resolution algorithm is applied to find a
resource. The idea is to have a path configuration like the Java CLASSPATH or
the *nix PATH environment variable list a series of absolute path prefixes
which are applied to the relative path in turn to find an existing resource.
Currently this mechanism is implemented in the sling/servlet-resolver project
in a combination of the SlingServletResolver and the PathSupport class. This
implementation must be cleaned up, such that this path searching may also be
used for other use cases.
(2) PathMapper
The jcr/resource project currently has an interface called PathResolver. This
interface defines an API to resolve an absolute path (technically this would be
the path part of an URI) into a Resource and to convert a resource path back to
a string which may be used as (part) of path part of an URI. Ideally the
methods should support roundtripping.
The use of such a mapper would be for scripts to be able to create uniform URIs
from resource paths and likewise some helper functionality may be built to
verify any path of an URI may correctly be resolved to a Resource.
To make this interface a real part of the Sling API and to prevent a naming
collision with the PathResolver, which resolves relative paths, the existing
PathResolver interface of the jcr/resource project is moved to the Sling API
and renamed to PathMapper.
Fix Version/s: 2.0.0
Summary: Extend ResourceResolver to make it more flexible (was:
Define PathResolver and PathMapper API)
Modifiy this issue to not create new interfaces but to extend the existing
ResourceResolver interface
> Extend ResourceResolver to make it more flexible
> ------------------------------------------------
>
> Key: SLING-198
> URL: https://issues.apache.org/jira/browse/SLING-198
> Project: Sling
> Issue Type: Improvement
> Components: API, Resource, ServletResolver
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> As a result of defining a virtual resource tree (SLING-197) we have a need to
> modify the ResourceResolver API in two respects:
> (1) Add ResourceResolver.resolve(String absPath)
> This method behaves exactly as ResourceResolver.resolve(HttpServletRequest)
> except, that the latter method may make use of additional request properties,
> such as request headers or parameters while the resolve(String) method only
> has the string to work on.
> Currently the resolve(HttpServletRequest) method does nothing more than use
> the HttpServletRequest.getPathInfo() to resolve the resource, thus both
> implementations would actually be equivalent.
> The absPath argument is an absolute path. Resolution fails for relative paths.
> (2) Support relative paths in ResourceResolver.getResource(String path)
> Currently this method is defined to throw a SlingException if the path is
> relative. This should be changed such that the ResourceResolver applies some
> search path logic to find a resource with the given relative path
> The search path logic is comparable to how *nix systems use the PATH
> environment variable.
> This method may then be used by multiple users such as Servlet/Script
> resolution.
> (3) Add ResourceResolver.map(Resource) method
> This method applies the reverse mappings of the
> ResourceResolver.resolve(String absPath) method to return a path suitable for
> both resolver() methods. This allows for the creation of link paths for
> resources.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
