Well, so the main argument is badly written code?
2014-08-18 19:35 GMT+02:00 Dominik Süß <[email protected]>: > Hi Carsten, > > I've played around with filters a lot and the problem with them really is > that they often have way to much impact and are not constrainted as they > would need to be. Even those filters skipping often create a lot of > overhead because they do not skip fast and with cheap evaluations but > instanciate expensive objects and so on. > > Therefore some easy but well performing mechanisms to perform checks in > first place would really help to avoid uncessary overhead in the request > livecycle. > > Additionally the option to block filters in specific cases without > deployment would be really something that would help a lot in production > where waiting for some vendor to fix a filter might take way to long ;) > > Cheers > Dominik > > On Mon, Aug 18, 2014 at 1:17 PM, 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] > > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
