[
https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger reopened SLING-227:
-------------------------------------
Thanks for looking into this. While this is not directly linked to the new
resolution mechanism (this would have been done like this before, I think), it
is of course something we have to care for, in that we only will accept an
existing resource in case it is not the same as the "current" resource.
This might also be caused by the situation, that the
ResourceResolver.resolve(String) method is implemented as if it would be used
in a non-GET/HEAD context. Probably, we should define this method as if it
would be used in a GET/HEAD context. Thus it will not consider the parent path
of a non-existing resource.
> sling:include tag: use ResourceResolver.resolve(String) method to get the
> resource
> ----------------------------------------------------------------------------------
>
> Key: SLING-227
> URL: https://issues.apache.org/jira/browse/SLING-227
> Project: Sling
> Issue Type: Bug
> Components: JSP
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> In case of using the path attribute of the sling:include tag, the resource is
> resolved from that path using the ResourceResolver.getResource() method. If
> the path contains any selectors and/or extension, the getResource() method
> fails.
> The sling:include tag should be fixed to request a RequestDispatcher based on
> the path if the path attribute is given instead of resolving the resource
> itself, because this duplicates code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
