You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2008/02/06 14:35:08 UTC
[jira] Created: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the 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.
[jira] Closed: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-227.
-----------------------------------
Resolution: Fixed
Do not actually use the resolved resource just use it to test whether a SyntheticResource must be created or not. Finally retrieve the RequestDispatcher with the resource or the path depending on what is available.
Fixed in Rev. 618997
> 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.
[jira] Closed: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-227.
-----------------------------------
Resolution: Fixed
After fixing SLING-230, I close this issue again, as the resolve cannot resolve a missing child resource any more and thus returns null instead of the current 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.
[jira] Commented: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566494#action_12566494 ]
Felix Meschberger commented on SLING-227:
-----------------------------------------
No, as I say in SLING-230, it is probably an error, that the resolve() methods consider the parent path at all, because those methods are not able to decide whether to go up the path or not on their own just based on some method names. This is application specific and must be handled in the application.
> 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.
[jira] Commented: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566193#action_12566193 ]
Felix Meschberger commented on SLING-227:
-----------------------------------------
I cannot reproduce this, in fact, the code:
if (path != null) {
if (!path.startsWith("/")) {
path = request.getResource().getPath() + "/" + path;
}
path = JcrResourceUtil.normalize(path);
}
will most certainly make the path absolute prefixing it with the current request's resource path.
> 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.
[jira] Commented: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566489#action_12566489 ]
Tobias Bocanegra commented on SLING-227:
----------------------------------------
> This might also be caused by the situation, that the ResourceResolver.resolve(String) method is implemented as ...
that's what i meant :-) maybe we should split those methods:
ResourceResolver.resolve(String)
ResourceResolver.resolveFromURL(String)
and remove any path scanning logic from the first one. so you always know what you get.
> 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.
[jira] Issue Comment Edited: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566414#action_12566414 ]
tripod edited comment on SLING-227 at 2/6/08 4:34 PM:
----------------------------------------------------------------
the problem is along this lines:
// check whether the path (would) resolve, else SyntheticRes.
Resource tmp = request.getResourceResolver().resolve(path);
if (tmp == null && resourceType != null) {
opts = null; // not needed
resource = new SyntheticResource(path, resourceType);
}
here the 'tmp' resolves to 'this' resource instead to NULL. could this be related to the new
resolution stuff ?
debugging of <sling:inlcude path="header"/> on /content/geometrixx/en/about/cq:content shows:
normalized path = /content/geometrixx/en/about/cq:content/header
tmp = JcrNodeResource, type=geometrixx/components/contentpage, path=/content/geometrixx/en/about/cq:content
the problem is, that the requested resource does not exist, and the sling include used to ignore this include. now the resource resolution returns the parent resource:
private Resource scanPath(String uriPath, String httpMethod)
throws SlingException {
Resource resource = null;
String curPath = uriPath;
try {
final ResourcePathIterator it = new ResourcePathIterator(uriPath,
httpMethod);
while (it.hasNext() && resource == null) {
curPath = it.next();
resource = getResourceInternal(curPath);
}
} catch (Exception ex) {
throw new SlingException("Problem trying " + curPath
+ " for request path " + uriPath, ex);
}
return resource;
}
was (Author: tripod):
the problem is along this lines:
// check whether the path (would) resolve, else SyntheticRes.
Resource tmp = request.getResourceResolver().resolve(path);
if (tmp == null && resourceType != null) {
opts = null; // not needed
resource = new SyntheticResource(path, resourceType);
}
here the 'tmp' resolves to 'this' resource instead to no one. could this be related to the new
resolution stuff ?
debugging of <sling:inlcude path="header"/> on /content/geometrixx/en/about/cq:content shows:
normalized path = /content/geometrixx/en/about/cq:content/header
tmp = JcrNodeResource, type=geometrixx/components/contentpage, path=/content/geometrixx/en/about/cq:content
the problem is, that the requested resource does not exist, and the sling include used to ignore this include. now the resource resolution returns the parent resource:
private Resource scanPath(String uriPath, String httpMethod)
throws SlingException {
Resource resource = null;
String curPath = uriPath;
try {
final ResourcePathIterator it = new ResourcePathIterator(uriPath,
httpMethod);
while (it.hasNext() && resource == null) {
curPath = it.next();
resource = getResourceInternal(curPath);
}
} catch (Exception ex) {
throw new SlingException("Problem trying " + curPath
+ " for request path " + uriPath, ex);
}
return 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.
[jira] Reopened: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566414#action_12566414 ]
Tobias Bocanegra commented on SLING-227:
----------------------------------------
the problem is along this lines:
// check whether the path (would) resolve, else SyntheticRes.
Resource tmp = request.getResourceResolver().resolve(path);
if (tmp == null && resourceType != null) {
opts = null; // not needed
resource = new SyntheticResource(path, resourceType);
}
here the 'tmp' resolves to 'this' resource instead to no one. could this be related to the new
resolution stuff ?
debugging of <sling:inlcude path="header"/> on /content/geometrixx/en/about/cq:content shows:
normalized path = /content/geometrixx/en/about/cq:content/header
tmp = JcrNodeResource, type=geometrixx/components/contentpage, path=/content/geometrixx/en/about/cq:content
the problem is, that the requested resource does not exist, and the sling include used to ignore this include. now the resource resolution returns the parent resource:
private Resource scanPath(String uriPath, String httpMethod)
throws SlingException {
Resource resource = null;
String curPath = uriPath;
try {
final ResourcePathIterator it = new ResourcePathIterator(uriPath,
httpMethod);
while (it.hasNext() && resource == null) {
curPath = it.next();
resource = getResourceInternal(curPath);
}
} catch (Exception ex) {
throw new SlingException("Problem trying " + curPath
+ " for request path " + uriPath, ex);
}
return 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.
[jira] Commented: (SLING-227) sling:include tag: use
ResourceResolver.resolve(String) method to get the resource
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566162#action_12566162 ]
Tobias Bocanegra commented on SLING-227:
----------------------------------------
the latest fix produces endless loops when including <sling:include path="foobar"/>
in this case the script of 'this' resource is included.
> 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.