[
https://issues.apache.org/jira/browse/SLING-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758699#action_12758699
]
Felix Meschberger edited comment on SLING-864 at 9/23/09 6:43 AM:
------------------------------------------------------------------
Following up to the discussion at [1] and agreeing with Bertrands proposal here
is a simple patch to set the resource metadata where it should be done:
Index: JcrResourceResolver2.java
===================================================================
--- JcrResourceResolver2.java (Revision 818098)
+++ JcrResourceResolver2.java (Arbeitskopie)
@@ -231,10 +231,21 @@
// if no resource has been found, use a NonExistingResource
if (res == null) {
+ String resourcePath = ensureAbsPath(realPathList[0]);
log.debug(
"resolve: Path {} does not resolve, returning
NonExistingResource at {}",
- absPath, realPathList[0]);
- res = new NonExistingResource(this,
ensureAbsPath(realPathList[0]));
+ absPath, resourcePath);
+ res = new NonExistingResource(this, resourcePath);
+
+ // SLING-864: if the path contains a dot we assume this to be
+ // the start for any selectors, extension, suffix, which may be
+ // used for further request processing.
+ int index = resourcePath.indexOf('.');
+ if (index != -1) {
+ res.getResourceMetadata().setResolutionPathInfo(
+ resourcePath.substring(index));
+ }
+
} else {
log.debug("resolve: Path {} resolves to Resource {}", absPath,
res);
}
[1] http://markmail.org/thread/4kqlegvnfq44p6qw
was (Author: fmeschbe):
Following up to the discussion at [1] and agreeing with Bertrands proposal
here is a simple patch to set the resource metadata where it should be done:
Index: JcrResourceResolver2.java
===================================================================
--- JcrResourceResolver2.java (Revision 818098)
+++ JcrResourceResolver2.java (Arbeitskopie)
@@ -231,10 +231,21 @@
// if no resource has been found, use a NonExistingResource
if (res == null) {
+ String resourcePath = ensureAbsPath(realPathList[0]);
log.debug(
"resolve: Path {} does not resolve, returning
NonExistingResource at {}",
- absPath, realPathList[0]);
- res = new NonExistingResource(this,
ensureAbsPath(realPathList[0]));
+ absPath, resourcePath);
+ res = new NonExistingResource(this, resourcePath);
+
+ // SLING-864: if the path contains a dot we assume this to be
+ // the start for any selectors, extension, suffix, which may be
+ // used for further request processing.
+ int index = resourcePath.indexOf('.');
+ if (index != -1) {
+ res.getResourceMetadata().setResolutionPathInfo(
+ resourcePath.substring(index));
+ }
+
} else {
log.debug("resolve: Path {} resolves to Resource {}", absPath,
res);
}
> Parse path info for NonExistingResource
> ---------------------------------------
>
> Key: SLING-864
> URL: https://issues.apache.org/jira/browse/SLING-864
> Project: Sling
> Issue Type: Improvement
> Components: API
> Affects Versions: API 2.0.2
> Reporter: Alexander Klimetschek
> Attachments: SLING-nonexisting-pathinfo.patch
>
>
> As proposed on the mailing list http://markmail.org/message/52m32zh36ewo4xl2,
> it would be helpful if the sling:nonexisting resource type would support
> selectors and extensions similar to normal resources.
> Currently you can only register one servlet per HTTP method for nonexisting
> resources. For example, this makes it impossible to add multiple importer
> servlets, that import different file formats into the repository at
> non-existing locations (they would create the necessary path). It would be
> good to register them on an extension-basis, eg. to do a POST to
> /content/calendar.ics for an icalendar file, a POST to /content/i18n.xliff
> for an xliff file, etc., with one servlet handling each import.
> Important to note is that until now, the contract of the NonExistingResource
> case was that sling did not try to parse anything and simply return the full
> URL as the resource path - even if it contains dots at the end. Selectors and
> extension in the request path info were always null. The sling post servlet
> for example relies on that by using the path to create a real resource there.
> Since this is already part of the released API, changing that contract is not
> really an option.
> In a f2f discussion with Felix and Carsten we came up with the solution to
> keep the full path for the nonexisting resource path but additionally try to
> parse the selectors and extension. This will make the script resolution work
> just as for existing resource while not breaking the existing contract.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
