[
https://issues.apache.org/jira/browse/SLING-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874150#comment-13874150
]
Olaf Otto commented on SLING-3319:
----------------------------------
I have analyzed potential ways to alter this behavior. Removing the
extension(s) during the split() or during the resolution phase later on has
undesired side effects (i.e., bugs). For instance, the ResourceProviderEntry
infers semantics from the number of elements resolved:
{code:java}
// query: /libs/sling/servlet/default
// resource Provider: libs/sling/servlet/default/GET.servlet
// list will match libs, sling, servlet, default
// and there will be no resource provider at the end
if (entries.size() > 0 && entries.size() == elements.length) {
if (entries.get(entries.size() - 1).getResourceProviders().length == 0)
{
logger.debug("Resolved Synthetic {}", fullPath);
return new SyntheticResource(resourceResolver, fullPath,
ResourceProvider.RESOURCE_TYPE_SYNTHETIC);
}
}
{code}
I believe the underlying issue is a lack of distinction between the lookup path
(created by the ResourceResolverImpl using a ResourcePathIterator) and the
original path as passed to the ResourceResolver. In my opinion, the original
path should be preserved and passed to the resolver obtained via the path
created by the ResourcePathIterator.
I have modified the ResourceResolverImpl to this extend, and ran both the unit
tests and some integration tests against a CMS project using Sling - so far I
spotted no error. However, this is a very sensitive change and must be reviewed
with care.
> ResourceProvider does not receive selectors or extensions when root path is
> resolved.
> -------------------------------------------------------------------------------------
>
> Key: SLING-3319
> URL: https://issues.apache.org/jira/browse/SLING-3319
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: Resource Resolver 1.0.6
> Reporter: Olaf Otto
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> In order to find and sort ResourceProviders, the ResourceProviderEntry class
> from org.apache.sling.resourceprovider splits the request path into segments,
> subsequently traversing the segments to find provides with a root matching
> the entire path up to the current segment. However, The function
> split(String) of ResourceProviderEntry splits by "/", thus resulting in the
> last segment containing any selectors and extensions of the current path,
> like so:
> /content/test/root.html -> [content, test, root.html].
> Thus a provider with a root path of /content/test/root is not found. The next
> iteration in ResourceResolver# resolveInternal(String absPath) will then
> provide /content/test/root to the ResourceProviderEntry. The provider is thus
> found, but invoked with /content/test/root (without any extensions or
> selectors).
> However when requesting a child resource:
> /content/test/root.html -> [content, test, root, child.html]
> the provider for root is found and thus invoked with
> /content/test/root/child.html , i.e. including any selectors and suffixes.
> In essence, a ResourceProvider can not utilize any selectors or extensions to
> parametrize the resolution of its root resource.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
