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] Updated: (SLING-1432) Unable to Forward to Images via a Filter

     [ 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.