Hi Carsten, While path-based filtering can be done with plain servlet filters, those don't have access to a ResourceResolver/Session/current Resource. Which makes them suitable for some use cases, but not others.
Regards, Justin On Mon, Aug 18, 2014 at 7:17 AM, Carsten Ziegeler <[email protected]> wrote: > Do we really really need this? At least path based filtering can be done > with plain servlet filters already. > > What are the use cases for this? > > Carsten > > > 2014-08-18 13:07 GMT+02:00 Felix Meschberger <[email protected]>: > >> Hi >> >> I am not sure, whether we should go down that route. >> >> A filter ist something which is a cross-cutting concern that the >> application places on the request processing. As such it is transparent to >> the client and it should not be client adressable. Otherwise unexpected >> behaviour is guaranteed. >> >> Regards >> Felix >> >> Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz <[email protected] >> >: >> >> > Hi, >> > >> > On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger <[email protected]> >> wrote: >> >> ... * filter.resourceType: The Filter is only called if the resourceType >> >> of the current Resource (SlingHttpServletRequest.getResource) >> >> matches any of the given resource types... >> > >> > I've long been thinking that we should allow Sling's script/servlet >> > resolution logic to be used for more than finding request processing >> > servlets. >> > >> > Is it something that would apply here? >> > >> > I'm not sure how that could work, but as an initial experiment we >> > could add a SLING-FILTER selector to the request, resolve that to a >> > servlet and expect that to be a Filter. And if that works define that >> > better as presented like this it's quite a hack ;-) >> > >> > -Bertrand >> >> > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
