Hi Carsten, Here's a few: * I need to be able to modify a JSON object returned by a servlet, for example to reorder objects in an array. In these cases, I have written a filter which gets the serialized object returned by the servlet, parses it, transforms it, and serializes it. * I need to be able to skip an included resource based on some criteria (a feature flag, a user profile, etc.). This can be done by logic in the resource type's script, having it in a filter would be a nicer separation of concerns. * Something like CORS (which IMHO should be configurable on a resource-type-level basis) would benefit from declarative configuration.
TBC, nothing that Felix wrote originally can't be done today by writing code inside the filter. But I think it would be more obvious (and easier to configure) if it was done declaratively. Justin On Tue, Aug 19, 2014 at 12:27 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > Right, can we list some use cases for that stuff here? > > Carsten > > > 2014-08-19 16:46 GMT+02:00 Justin Edelson <jus...@justinedelson.com>: > >> 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 <cziege...@apache.org> >> 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 <fmesc...@adobe.com>: >> > >> >> 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 < >> bdelacre...@apache.org >> >> >: >> >> >> >> > Hi, >> >> > >> >> > On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger < >> fmesc...@adobe.com> >> >> 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 >> > cziege...@apache.org >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
