[jira] Updated: (SLING-198) Extend ResourceResolver to make it more flexible

["Felix Meschberger (JIRA)" <ji...@apache.org>]

     [ 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.