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