On Mon, Mar 31, 2008 at 3:25 PM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Mon, Mar 31, 2008 at 3:10 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > Am Montag, den 31.03.2008, 14:52 +0200 schrieb Bertrand Delacretaz: > > > > > > ...The easiest seems to be for your filter to be declared in web.xml.... > > >... This is certainly a possibility, but I would not go this route as it > > > leaves Sling and makes it impossible to be used in the standalone > > launchpad/app case... In addition it is impossible to manage, ie > > configure and updated the filter.... > > Agreed - I was suggesting a "here and now" solution, but I agree that > it is not really integrated with Sling.
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? > As I said before, though, I'm not too enthusiastic about SLING-249, as > httpd's mod_proxy handles that very nicely. I wouldn't add complexity > to Sling to handle that, unless that complexity is cleanly isolated in > a component like a filter. Errr, I'm not too enthusiastic about mod_proxy :) As mod_proxy would have to live outside Sling, it would not be able to intercept sling.include requests. So that a request from a browser to http://www.domain.com/path would yield a different result than sling.include("/path"). In a perfect world (tm), the host information would still be available for handling the sling.include request. -- Vidar S. Ramdal <[EMAIL PROTECTED]> - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
