You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Jason Rose (JIRA)" <ji...@apache.org> on 2010/03/09 23:44:27 UTC
[jira] Created: (SLING-1432) Unable to Forward to Images via a
Filter
Unable to Forward to Images via a Filter
----------------------------------------
Key: SLING-1432
URL: https://issues.apache.org/jira/browse/SLING-1432
Project: Sling
Issue Type: Bug
Components: Extensions, Servlets
Reporter: Jason Rose
Attachments: UuidFilter.java
In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter.
The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path.
i.e:
posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa. Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' filters it to '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' and it works correctly.
This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy.
Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually.
i.e:
posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg.
Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' leads to a 404.
Accessing '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' returns the correct resource.
Putting a new image also called img.jpg under /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa with a dav, then hitting the first path in the browser will return the new image, which isn't correct.
It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1432) Unable to Forward to Images via a
Filter
Posted by "Jason Rose (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Rose updated SLING-1432:
------------------------------
Description:
In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter.
The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path.
i.e:
posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa. Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' filters it to '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' and it works correctly.
This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy.
Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually.
i.e:
posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg.
Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' leads to a 404.
Accessing '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' returns the correct resource.
Putting a new image also called img.jpg under /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa with a dav, then hitting the first path in the browser will the image stored at the bucketed path.
It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state?
was:
In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter.
The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path.
i.e:
posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa. Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' filters it to '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' and it works correctly.
This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy.
Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually.
i.e:
posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg.
Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' leads to a 404.
Accessing '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' returns the correct resource.
Putting a new image also called img.jpg under /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa with a dav, then hitting the first path in the browser will return the new image, which isn't correct.
It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state?
> Unable to Forward to Images via a Filter
> ----------------------------------------
>
> Key: SLING-1432
> URL: https://issues.apache.org/jira/browse/SLING-1432
> Project: Sling
> Issue Type: Bug
> Components: Extensions, Servlets
> Reporter: Jason Rose
> Attachments: UuidFilter.java
>
>
> In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter.
> The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa. Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' filters it to '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' and it works correctly.
> This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy.
> Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg.
> Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' leads to a 404.
> Accessing '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' returns the correct resource.
> Putting a new image also called img.jpg under /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa with a dav, then hitting the first path in the browser will the image stored at the bucketed path.
> It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1432) Unable to Forward to Images via a
Filter
Posted by "Jason Rose (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Rose updated SLING-1432:
------------------------------
Attachment: UuidFilter.java
This is the filter I'm using.
> Unable to Forward to Images via a Filter
> ----------------------------------------
>
> Key: SLING-1432
> URL: https://issues.apache.org/jira/browse/SLING-1432
> Project: Sling
> Issue Type: Bug
> Components: Extensions, Servlets
> Reporter: Jason Rose
> Attachments: UuidFilter.java
>
>
> In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter.
> The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa. Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' filters it to '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' and it works correctly.
> This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy.
> Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg.
> Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' leads to a 404.
> Accessing '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' returns the correct resource.
> Putting a new image also called img.jpg under /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa with a dav, then hitting the first path in the browser will return the new image, which isn't correct.
> It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1432) Unable to Forward to Images via a
Filter
Posted by "Jason Rose (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849422#action_12849422 ]
Jason Rose commented on SLING-1432:
-----------------------------------
I can verify that once I call the request dispatcher with the correct path, the SlingHttpServletRequest.getResource() returns the correct resource (the image). I don't know what happens downstream to break this functionality. One thing I have noticed though, is that the request.getPathInfo(), pathuri, etc all still reference the old path. I don't know if some code after the filter is ignoring the getResource() method and is instead trying to find a resource based on the javax.servlet methods.
> Unable to Forward to Images via a Filter
> ----------------------------------------
>
> Key: SLING-1432
> URL: https://issues.apache.org/jira/browse/SLING-1432
> Project: Sling
> Issue Type: Bug
> Components: Extensions, Servlets
> Reporter: Jason Rose
> Attachments: uuid_filter_problem.log, UuidFilter.java
>
>
> In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter.
> The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa. Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' filters it to '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' and it works correctly.
> This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy.
> Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg.
> Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' leads to a 404.
> Accessing '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' returns the correct resource.
> Putting a new image also called img.jpg under /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa with a dav, then hitting the first path in the browser will the image stored at the bucketed path.
> It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1432) Unable to Forward to Images via a
Filter
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler resolved SLING-1432.
-------------------------------------
Resolution: Not A Problem
Your filter is a component filter and therefore comes too late in the game. A component filter is called whenever a component = script is invoked for rendering. This happens after the resource is resolved.
Unfortunately making this filter a sling request filter (filter.scope=request), doesn't solve your problem either as event sling request filters are called after the resource is resolved.
It works in the POST case as a POST is intended to create new resources.
Depending on the OSGi http service implementation you might be able to register a real servlet filter for the whole sling web application. This filter would run before Sling and solve your problem.
Another solution I see (which I would rather consider a workaround) would be to post/get to a path like /resources/XYZ while you store content
in the repository at /data/X/Y/Z. In this case you can register your own servlet through the http service at /resources and simple forward from
there to /data/ which is handled by Sling.
> Unable to Forward to Images via a Filter
> ----------------------------------------
>
> Key: SLING-1432
> URL: https://issues.apache.org/jira/browse/SLING-1432
> Project: Sling
> Issue Type: Bug
> Components: Extensions, Servlets
> Reporter: Jason Rose
> Attachments: uuid_filter_problem.log, UuidFilter.java
>
>
> In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter.
> The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa. Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' filters it to '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' and it works correctly.
> This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy.
> Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg.
> Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' leads to a 404.
> Accessing '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' returns the correct resource.
> Putting a new image also called img.jpg under /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa with a dav, then hitting the first path in the browser will the image stored at the bucketed path.
> It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1432) Unable to Forward to Images via a
Filter
Posted by "Jason Rose (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Rose updated SLING-1432:
------------------------------
Attachment: uuid_filter_problem.log
This is a copy of the log output.
> Unable to Forward to Images via a Filter
> ----------------------------------------
>
> Key: SLING-1432
> URL: https://issues.apache.org/jira/browse/SLING-1432
> Project: Sling
> Issue Type: Bug
> Components: Extensions, Servlets
> Reporter: Jason Rose
> Attachments: uuid_filter_problem.log, UuidFilter.java
>
>
> In my current application, I store nodes with the name of the node being a uuid generated by a sproutcore client. Because this doesn't directly lend itself to a deep node hierarchy, I have a filter in place that buckets these uuids into two more levels based on the first four characters in the uuid. I'd like this process to be transparent to the front end, so I use the filter.
> The filter itself is very simple. It checks the request.getPathInfo() for any uuids, buckets them according to a built-in strategy, then uses the request dispatcher to forward to the new path.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa. Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' filters it to '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa.xml' and it works correctly.
> This sort of approach seems to solve all the performance problems in jackrabbit and works in the general case, like when there isn't an obvious way to naturally get a deep hierarchy.
> Something breaks, though, when I try to bucket images. The node is posted correctly, but when I try to get it via the filter in the url, I get a 404. If I put an image with the same name under the unbucketed path using something like DAV, requesting an unbucketed resource that gets resolved by my filter will return the image I uploaded manually.
> i.e:
> posting to /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg ends up creating a node at /test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg.
> Accessing '/test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' leads to a 404.
> Accessing '/test/foo/ab/ba/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/img.jpg' returns the correct resource.
> Putting a new image also called img.jpg under /test/foo/abbaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa with a dav, then hitting the first path in the browser will the image stored at the bucketed path.
> It seems to me that the prep work done by sling before executing the filters leads to a dirty state that disallows me from forwarding to a new path in my filter. Is there a way to clean up the request's state?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.