Nah. You should be able to do it with SCR. Just be sure to set the pattern property. See http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheWhiteboard
Justin On Wed, Mar 10, 2010 at 12:47 PM, Jason Rose <[email protected]> wrote: > I'll try this. I was looking into it yesterday shortly before I opened the > issue, but I hadn't found an easy way to do it with just SCR annotations. > All the examples that I've found involve using the service registry to pull > up the HttpService and registering it with that. > > Thank you > > > On Mar 10, 2010, at 10:36 AM, Justin Edelson wrote: > > Jason- >> I haven't had a chance to look at the details of your issue, but have >> you thought about registering your Filter *outside* of Sling (i.e. with >> the HttpService)? >> >> Justin >> >> On 3/10/10 12:32 PM, Jason Rose wrote: >> >>> Hello all, >>> >>> I have opened a jira case, SLING-1432, about an issue I'm currently >>> having with forwarding in a filter. I currently use a filter to force a >>> deeper node structure and present the illusion of it being very flat to >>> work around serious performance problems in jackrabbit while hiding that >>> from my application's front end. >>> >>> My filter itself is very simple. It looks at the request's pathinfo, >>> and if it matches a regex I forward the request to a deeper path. This >>> applies to both GET and POST. This seems to work fine for all nodes >>> that I use the provided output formatting servlets to retrieve, like >>> json, xml, txt, etc, but this doesn't work for static resources that I >>> just want stored, such as images, docs, etc. Trying to access those >>> resources leads to a 404 from sling, although I can verify that I >>> forward to the correct node. >>> >>> Looking at the log output, it looks like the JcrResourceResolver runs >>> before executing any filters I provide, and does not run again after >>> being forwarded from my filter. I think that some state in the >>> SlingHttpServletRequest object isn't being cleaned up in the case of a >>> forward from a filter registered with Sling. I'm still not sure though. >>> >>> Does anybody have any idea why this strategy doesn't work for simple >>> content but does for anything being loaded and serialized by sling >>> itself? >>> >>> -Jason >>> >> >> >
