Hi, Am Montag, den 31.03.2008, 16:07 +0200 schrieb Vidar Ramdal: > On Mon, Mar 31, 2008 at 3:54 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > OK - how about introducing a new filter.scope - e.g. "prerequest", and > > > alter SlingMainServlet so that it invokes "prerequest" filters before > > > passing the request to the ResourceResolver? > > > > Sounds interesting. Such a filter would be defined to get the original > > request and response objects from the servlet container. That is they > > would be HttpServletRequest/Response and not > > SlingHttpServletRequest/Response. > > > > Would that suit your needs ? > > Ah ... but this would be a catch 22, wouldn't it, as the sling.include > scenario will still be a problem: > > > So that a request from a browser to http://www.domain.com/path would > > yield a different result than sling.include("/path"). > > Or am I missing something here? >
Yes and no ;-) If you use SlingScriptHelper.include which takes a path, you would somehow have to guard the ResourceResolver returned from the SlingHttpServletRequest which is used to resolve the path to a resource. In this respect, this would have to be considered, yes. What could also be done to runt the "prerequest" filters with incompletely setup SlingHttpServletRequest/Response objects. This would mean the request.getResource() might return null in this stadium. This would allow a filter to overwrite the SlingHttpServletRequest.getResourceResolver() method to wrap the ResourceResolver with some special functionality ... Regards Felix
