Re: Sling Request Filter "filtering"
Hi Am 19.08.2014 um 11:20 schrieb Julian Sedding : > Could this be solved with an abstract class that supports additional > properties to decide whether to bypass the filter or not? Sure, that’s the traditional Java-based approach — which can still be implemented, but maybe not by Sling unless we go the OptingFilter route sometime in the future. With the proposed service properties we have a much more versatile way of filtering: While the Java based approach in general requires code changes and bundle deployments, the service property based approach can be supported by simply providing appropriate configuration. This can be done at runtime by the system administrator. Regards Felix > > This would of course not help with implementations that aren't > well-behaved. However, it would lower the hurdle to implement > well-behaved filters. > > Personally I would favour such a solution, because it is opt-in and > keeps the "core" implementation lean. > > Regards > Julian > > > On Tue, Aug 19, 2014 at 9:32 AM, Dominik Süß wrote: >> To be honest, for me it currently is the main reason. And the code I'm >> refering to is owned by a vendor and getting hotfixes can take way to long. >> >> Aditionally right now writting working code is pretty easy but there is no >> support that helps to write proper skipping (cheap and early) of filters >> and therefore to write well performing and low impact filters. Giving some >> OOTB features for such a mighty extensionpoint as Filters seems like a good >> idea making it easy to write good code. >> >> As shown with the ColumnCtrlFilter developers sometimes do simply not >> realize that they might be way to intrusive because in the current state of >> applications the filters do no harm. >> >> Dominik >> >> >> On Mon, Aug 18, 2014 at 10:25 PM, Carsten Ziegeler >> wrote: >> >>> Well, so the main argument is badly written code? >>> >>> >>> 2014-08-18 19:35 GMT+02:00 Dominik Süß : >>> 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 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 : > >> 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 >>>
Re: Sling Request Filter "filtering"
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 wrote: > Right, can we list some use cases for that stuff here? > > Carsten > > > 2014-08-19 16:46 GMT+02:00 Justin Edelson : > >> 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 >> 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 : >> > >> >> 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
Re: Sling Request Filter "filtering"
Right, can we list some use cases for that stuff here? Carsten 2014-08-19 16:46 GMT+02:00 Justin Edelson : > 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 > 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 : > > > >> 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
Re: Sling Request Filter "filtering"
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 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 : > >> 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 > >: >> >> > Hi, >> > >> > On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger >> 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
Re: Sling Request Filter "filtering"
Hi Dominik, IIUC, the idea of Felix's original proposal was that the filter developer and deployer could declaratively determine the specific set of resource types to which a filter should be executed (whereas currently that can only be done programatically and is largely ad hoc when done at all). That would seem to solve for the problem you identify where a filter only should get executed for certain resource types. Because the platform doesn't have this capability today, *of course* there are cases now where filters are executed when they shouldn't. IMHO, adding a negative configuration option, i.e. only execute this filter *unless* the resource type doesn't match, is adding unnecessary complexity. And even if it is deemed necessary, what Felix proposed should be done first and then the need to have a negative option can be reevaluated. Regards, Justin On Mon, Aug 18, 2014 at 1:38 PM, Dominik Süß wrote: > Hi Justin, > I'm not talking about global disable because the filter often is extremely > necessary but to be able to disable it for dedicated cases. I just remember > some obscure ColumnControlFilter only checking for the Pathending colctrl > and autorewriting the node underneath. Turning off that filter would break > a lot of funcitonality but it did mess around with nodes with a specific > resourcetype, so I was missing an option to deactivate it for this very > specific resourceType. > > Best regards > Dominik > > > On Mon, Aug 18, 2014 at 7:33 PM, Justin Edelson > wrote: > >> Hi, >> >> On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß >> wrote: >> > Hi Felix, >> > >> > you probably remember our discussion - I checked and found out that >> > resourceresolution is done with adminsession anyways and >> superTypeHierarchy >> > being cached (at least from what I remember) therefore this shouldn't add >> > much overhead. >> > >> > IMHO an important point is that it needs to be possible to add rules >> > without deployment. What I have in mind is some kind of blacklisting of >> > filters that "by accident" act in a situation where they shouldn't. In an >> > ideal world a dev directly can fix that, in reallity the filter might be >> > owned by a third party and cannot be directly fixed and therefore be a >> > blocker. >> >> Assuming this is all done by service registration properties, it is >> all configurable. Just set the filter.ignore property to true. Whether >> or not this counts as a "deployment" is up to you I suppose :) >> >> Regards, >> Justin >> >> > >> > Cheers >> > Dominik >> > >> > >> > On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger >> > wrote: >> > >> >> Hi >> >> >> >> Am 18.08.2014 um 12:08 schrieb Jeff Young : >> >> >> >> > Hi Felix, >> >> > >> >> > I think to reduce the unexpected you'd need filter.resourceType to >> match >> >> > on the resource's supertype hierarchy too. >> >> >> >> Yeah, match could be ResourceUtil.isA(). But it should not be adding to >> >> much overhead for the request processing. >> >> >> >> Regards >> >> Felix >> >> >> >> > >> >> > Cheers, >> >> > Jeff. >> >> > >> >> > >> >> > On 18/08/2014 10:23, "Felix Meschberger" wrote: >> >> > >> >> >> Hi all >> >> >> >> >> >> I had various discussions around execution of Servlet API Filters in >> the >> >> >> Sling Engine. >> >> >> >> >> >> To recap: Currently all filters are always called. The >> service.ranking >> >> >> (or filter.order) service registration property can be used to define >> >> the >> >> >> order in which the filters are called and the filter.scope property >> is >> >> >> required to indicate at what stage in the request processing a filter >> >> has >> >> >> to be called. See [1] for the full story. >> >> >> >> >> >> Turns out, that it would be good to have some simple and global >> flags to >> >> >> indicate when a filter should actually be called or not. This would >> be >> >> >> similar to the filter mappings of traditional web applications, where >> >> >> filters are bound to URL paths and/or servlets. >> >> >> >> >> >> So I am proposing to introduce three new service registration >> >> properties, >> >> >> which may be set on Servlet Filter services handled by the Sling >> Engine: >> >> >> >> >> >> * filter.path: The Filter is only called if the path of the >> >> >> current Resource (SlingHttpServletRequest.getResource) >> >> >> matches any of the given paths. If the property is >> >> >> not set, the filter will always be called. >> >> >> * filter.resourceType: The Filter is only called if the resourceType >> >> >> of the current Resource (SlingHttpServletRequest.getResource) >> >> >> matches any of the given resource types. If the property is >> >> >> not set, the filter will always be called. >> >> >> * filter.ignore: The Filter is never called if this property >> >> >> is set to any "true". >> >> >> >> >> >> >> >> >> The implementation would be as follows: >> >> >> >> >> >> * The FilterListEntry class is augmented with a method to verify >> whether >> >> >>
Re: Sling Request Filter "filtering"
Could this be solved with an abstract class that supports additional properties to decide whether to bypass the filter or not? This would of course not help with implementations that aren't well-behaved. However, it would lower the hurdle to implement well-behaved filters. Personally I would favour such a solution, because it is opt-in and keeps the "core" implementation lean. Regards Julian On Tue, Aug 19, 2014 at 9:32 AM, Dominik Süß wrote: > To be honest, for me it currently is the main reason. And the code I'm > refering to is owned by a vendor and getting hotfixes can take way to long. > > Aditionally right now writting working code is pretty easy but there is no > support that helps to write proper skipping (cheap and early) of filters > and therefore to write well performing and low impact filters. Giving some > OOTB features for such a mighty extensionpoint as Filters seems like a good > idea making it easy to write good code. > > As shown with the ColumnCtrlFilter developers sometimes do simply not > realize that they might be way to intrusive because in the current state of > applications the filters do no harm. > > Dominik > > > On Mon, Aug 18, 2014 at 10:25 PM, Carsten Ziegeler > wrote: > >> Well, so the main argument is badly written code? >> >> >> 2014-08-18 19:35 GMT+02:00 Dominik Süß : >> >> > 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 >> > 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 : >> > > >> > > > 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 >>
Re: Sling Request Filter "filtering"
To be honest, for me it currently is the main reason. And the code I'm refering to is owned by a vendor and getting hotfixes can take way to long. Aditionally right now writting working code is pretty easy but there is no support that helps to write proper skipping (cheap and early) of filters and therefore to write well performing and low impact filters. Giving some OOTB features for such a mighty extensionpoint as Filters seems like a good idea making it easy to write good code. As shown with the ColumnCtrlFilter developers sometimes do simply not realize that they might be way to intrusive because in the current state of applications the filters do no harm. Dominik On Mon, Aug 18, 2014 at 10:25 PM, Carsten Ziegeler wrote: > Well, so the main argument is badly written code? > > > 2014-08-18 19:35 GMT+02:00 Dominik Süß : > > > 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 > > 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 : > > > > > > > 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 >
Re: Sling Request Filter "filtering"
Well, so the main argument is badly written code? 2014-08-18 19:35 GMT+02:00 Dominik Süß : > 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 > 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 : > > > > > 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
Re: Sling Request Filter "filtering"
Hi Justin, I'm not talking about global disable because the filter often is extremely necessary but to be able to disable it for dedicated cases. I just remember some obscure ColumnControlFilter only checking for the Pathending colctrl and autorewriting the node underneath. Turning off that filter would break a lot of funcitonality but it did mess around with nodes with a specific resourcetype, so I was missing an option to deactivate it for this very specific resourceType. Best regards Dominik On Mon, Aug 18, 2014 at 7:33 PM, Justin Edelson wrote: > Hi, > > On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß > wrote: > > Hi Felix, > > > > you probably remember our discussion - I checked and found out that > > resourceresolution is done with adminsession anyways and > superTypeHierarchy > > being cached (at least from what I remember) therefore this shouldn't add > > much overhead. > > > > IMHO an important point is that it needs to be possible to add rules > > without deployment. What I have in mind is some kind of blacklisting of > > filters that "by accident" act in a situation where they shouldn't. In an > > ideal world a dev directly can fix that, in reallity the filter might be > > owned by a third party and cannot be directly fixed and therefore be a > > blocker. > > Assuming this is all done by service registration properties, it is > all configurable. Just set the filter.ignore property to true. Whether > or not this counts as a "deployment" is up to you I suppose :) > > Regards, > Justin > > > > > Cheers > > Dominik > > > > > > On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger > > wrote: > > > >> Hi > >> > >> Am 18.08.2014 um 12:08 schrieb Jeff Young : > >> > >> > Hi Felix, > >> > > >> > I think to reduce the unexpected you'd need filter.resourceType to > match > >> > on the resource's supertype hierarchy too. > >> > >> Yeah, match could be ResourceUtil.isA(). But it should not be adding to > >> much overhead for the request processing. > >> > >> Regards > >> Felix > >> > >> > > >> > Cheers, > >> > Jeff. > >> > > >> > > >> > On 18/08/2014 10:23, "Felix Meschberger" wrote: > >> > > >> >> Hi all > >> >> > >> >> I had various discussions around execution of Servlet API Filters in > the > >> >> Sling Engine. > >> >> > >> >> To recap: Currently all filters are always called. The > service.ranking > >> >> (or filter.order) service registration property can be used to define > >> the > >> >> order in which the filters are called and the filter.scope property > is > >> >> required to indicate at what stage in the request processing a filter > >> has > >> >> to be called. See [1] for the full story. > >> >> > >> >> Turns out, that it would be good to have some simple and global > flags to > >> >> indicate when a filter should actually be called or not. This would > be > >> >> similar to the filter mappings of traditional web applications, where > >> >> filters are bound to URL paths and/or servlets. > >> >> > >> >> So I am proposing to introduce three new service registration > >> properties, > >> >> which may be set on Servlet Filter services handled by the Sling > Engine: > >> >> > >> >> * filter.path: The Filter is only called if the path of the > >> >> current Resource (SlingHttpServletRequest.getResource) > >> >> matches any of the given paths. If the property is > >> >> not set, the filter will always be called. > >> >> * filter.resourceType: The Filter is only called if the resourceType > >> >> of the current Resource (SlingHttpServletRequest.getResource) > >> >> matches any of the given resource types. If the property is > >> >> not set, the filter will always be called. > >> >> * filter.ignore: The Filter is never called if this property > >> >> is set to any "true". > >> >> > >> >> > >> >> The implementation would be as follows: > >> >> > >> >> * The FilterListEntry class is augmented with a method to verify > whether > >> >> to call the filter at all > >> >> * The AbstractSlingFilterChain.doFilter method is augmented to call > this > >> >> new method and to not call a filter for which the match fails. A > >> >> RequestProgressTracker entry is generated for filters not called > >> >> indicating why it has not been called. > >> >> > >> >> Further extensions could be: > >> >> > >> >> * filter.expression: some scripting expression evaluating to > >> >> a boolean. If true the filter is called. > >> >> * Filter service implements a new interface providing an filter > >> >> expression method returning a boolean. If true the filter > >> >> is called (comparable to the option servlet). > >> >> > >> >> Regards > >> >> Felix > >> >> > >> >> [1] > http://sling.apache.org/documentation/the-sling-engine/filters.html > >> > > >> > >> >
Re: Sling Request Filter "filtering"
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 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 : > > > 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 >
Re: Sling Request Filter "filtering"
Hi, On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß wrote: > Hi Felix, > > you probably remember our discussion - I checked and found out that > resourceresolution is done with adminsession anyways and superTypeHierarchy > being cached (at least from what I remember) therefore this shouldn't add > much overhead. > > IMHO an important point is that it needs to be possible to add rules > without deployment. What I have in mind is some kind of blacklisting of > filters that "by accident" act in a situation where they shouldn't. In an > ideal world a dev directly can fix that, in reallity the filter might be > owned by a third party and cannot be directly fixed and therefore be a > blocker. Assuming this is all done by service registration properties, it is all configurable. Just set the filter.ignore property to true. Whether or not this counts as a "deployment" is up to you I suppose :) Regards, Justin > > Cheers > Dominik > > > On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger > wrote: > >> Hi >> >> Am 18.08.2014 um 12:08 schrieb Jeff Young : >> >> > Hi Felix, >> > >> > I think to reduce the unexpected you'd need filter.resourceType to match >> > on the resource's supertype hierarchy too. >> >> Yeah, match could be ResourceUtil.isA(). But it should not be adding to >> much overhead for the request processing. >> >> Regards >> Felix >> >> > >> > Cheers, >> > Jeff. >> > >> > >> > On 18/08/2014 10:23, "Felix Meschberger" wrote: >> > >> >> Hi all >> >> >> >> I had various discussions around execution of Servlet API Filters in the >> >> Sling Engine. >> >> >> >> To recap: Currently all filters are always called. The service.ranking >> >> (or filter.order) service registration property can be used to define >> the >> >> order in which the filters are called and the filter.scope property is >> >> required to indicate at what stage in the request processing a filter >> has >> >> to be called. See [1] for the full story. >> >> >> >> Turns out, that it would be good to have some simple and global flags to >> >> indicate when a filter should actually be called or not. This would be >> >> similar to the filter mappings of traditional web applications, where >> >> filters are bound to URL paths and/or servlets. >> >> >> >> So I am proposing to introduce three new service registration >> properties, >> >> which may be set on Servlet Filter services handled by the Sling Engine: >> >> >> >> * filter.path: The Filter is only called if the path of the >> >> current Resource (SlingHttpServletRequest.getResource) >> >> matches any of the given paths. If the property is >> >> not set, the filter will always be called. >> >> * filter.resourceType: The Filter is only called if the resourceType >> >> of the current Resource (SlingHttpServletRequest.getResource) >> >> matches any of the given resource types. If the property is >> >> not set, the filter will always be called. >> >> * filter.ignore: The Filter is never called if this property >> >> is set to any "true". >> >> >> >> >> >> The implementation would be as follows: >> >> >> >> * The FilterListEntry class is augmented with a method to verify whether >> >> to call the filter at all >> >> * The AbstractSlingFilterChain.doFilter method is augmented to call this >> >> new method and to not call a filter for which the match fails. A >> >> RequestProgressTracker entry is generated for filters not called >> >> indicating why it has not been called. >> >> >> >> Further extensions could be: >> >> >> >> * filter.expression: some scripting expression evaluating to >> >> a boolean. If true the filter is called. >> >> * Filter service implements a new interface providing an filter >> >> expression method returning a boolean. If true the filter >> >> is called (comparable to the option servlet). >> >> >> >> Regards >> >> Felix >> >> >> >> [1] http://sling.apache.org/documentation/the-sling-engine/filters.html >> > >> >>
Re: Sling Request Filter "filtering"
Hi Felix, you probably remember our discussion - I checked and found out that resourceresolution is done with adminsession anyways and superTypeHierarchy being cached (at least from what I remember) therefore this shouldn't add much overhead. IMHO an important point is that it needs to be possible to add rules without deployment. What I have in mind is some kind of blacklisting of filters that "by accident" act in a situation where they shouldn't. In an ideal world a dev directly can fix that, in reallity the filter might be owned by a third party and cannot be directly fixed and therefore be a blocker. Cheers Dominik On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger wrote: > Hi > > Am 18.08.2014 um 12:08 schrieb Jeff Young : > > > Hi Felix, > > > > I think to reduce the unexpected you'd need filter.resourceType to match > > on the resource's supertype hierarchy too. > > Yeah, match could be ResourceUtil.isA(). But it should not be adding to > much overhead for the request processing. > > Regards > Felix > > > > > Cheers, > > Jeff. > > > > > > On 18/08/2014 10:23, "Felix Meschberger" wrote: > > > >> Hi all > >> > >> I had various discussions around execution of Servlet API Filters in the > >> Sling Engine. > >> > >> To recap: Currently all filters are always called. The service.ranking > >> (or filter.order) service registration property can be used to define > the > >> order in which the filters are called and the filter.scope property is > >> required to indicate at what stage in the request processing a filter > has > >> to be called. See [1] for the full story. > >> > >> Turns out, that it would be good to have some simple and global flags to > >> indicate when a filter should actually be called or not. This would be > >> similar to the filter mappings of traditional web applications, where > >> filters are bound to URL paths and/or servlets. > >> > >> So I am proposing to introduce three new service registration > properties, > >> which may be set on Servlet Filter services handled by the Sling Engine: > >> > >> * filter.path: The Filter is only called if the path of the > >> current Resource (SlingHttpServletRequest.getResource) > >> matches any of the given paths. If the property is > >> not set, the filter will always be called. > >> * filter.resourceType: The Filter is only called if the resourceType > >> of the current Resource (SlingHttpServletRequest.getResource) > >> matches any of the given resource types. If the property is > >> not set, the filter will always be called. > >> * filter.ignore: The Filter is never called if this property > >> is set to any "true". > >> > >> > >> The implementation would be as follows: > >> > >> * The FilterListEntry class is augmented with a method to verify whether > >> to call the filter at all > >> * The AbstractSlingFilterChain.doFilter method is augmented to call this > >> new method and to not call a filter for which the match fails. A > >> RequestProgressTracker entry is generated for filters not called > >> indicating why it has not been called. > >> > >> Further extensions could be: > >> > >> * filter.expression: some scripting expression evaluating to > >> a boolean. If true the filter is called. > >> * Filter service implements a new interface providing an filter > >> expression method returning a boolean. If true the filter > >> is called (comparable to the option servlet). > >> > >> Regards > >> Felix > >> > >> [1] http://sling.apache.org/documentation/the-sling-engine/filters.html > > > >
Re: Sling Request Filter "filtering"
On Mon, Aug 18, 2014 at 1:07 PM, Felix Meschberger wrote: > ...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... I'm not saying we should make the filter client addressable. What I mean is that we have well known and well tested logic that selects scripts/servlets based on a resource type, supertype request method, selectors etc. Instead of reimplementing logic elsewhere to select things based on resource types, it might be better to factor out that logic so as to be able to reuse it *internally* to select other things - like Filters in this example. -Bertrand
Re: Sling Request Filter "filtering"
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 : > 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 >: > > > Hi, > > > > On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger > 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
Re: Sling Request Filter "filtering"
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 : > Hi, > > On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger > 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
Re: Sling Request Filter "filtering"
Hi Am 18.08.2014 um 12:08 schrieb Jeff Young : > Hi Felix, > > I think to reduce the unexpected you'd need filter.resourceType to match > on the resource's supertype hierarchy too. Yeah, match could be ResourceUtil.isA(). But it should not be adding to much overhead for the request processing. Regards Felix > > Cheers, > Jeff. > > > On 18/08/2014 10:23, "Felix Meschberger" wrote: > >> Hi all >> >> I had various discussions around execution of Servlet API Filters in the >> Sling Engine. >> >> To recap: Currently all filters are always called. The service.ranking >> (or filter.order) service registration property can be used to define the >> order in which the filters are called and the filter.scope property is >> required to indicate at what stage in the request processing a filter has >> to be called. See [1] for the full story. >> >> Turns out, that it would be good to have some simple and global flags to >> indicate when a filter should actually be called or not. This would be >> similar to the filter mappings of traditional web applications, where >> filters are bound to URL paths and/or servlets. >> >> So I am proposing to introduce three new service registration properties, >> which may be set on Servlet Filter services handled by the Sling Engine: >> >> * filter.path: The Filter is only called if the path of the >> current Resource (SlingHttpServletRequest.getResource) >> matches any of the given paths. If the property is >> not set, the filter will always be called. >> * filter.resourceType: The Filter is only called if the resourceType >> of the current Resource (SlingHttpServletRequest.getResource) >> matches any of the given resource types. If the property is >> not set, the filter will always be called. >> * filter.ignore: The Filter is never called if this property >> is set to any "true". >> >> >> The implementation would be as follows: >> >> * The FilterListEntry class is augmented with a method to verify whether >> to call the filter at all >> * The AbstractSlingFilterChain.doFilter method is augmented to call this >> new method and to not call a filter for which the match fails. A >> RequestProgressTracker entry is generated for filters not called >> indicating why it has not been called. >> >> Further extensions could be: >> >> * filter.expression: some scripting expression evaluating to >> a boolean. If true the filter is called. >> * Filter service implements a new interface providing an filter >> expression method returning a boolean. If true the filter >> is called (comparable to the option servlet). >> >> Regards >> Felix >> >> [1] http://sling.apache.org/documentation/the-sling-engine/filters.html >
Re: Sling Request Filter "filtering"
On Mon, Aug 18, 2014 at 12:08 PM, Jeff Young wrote: > ...I think to reduce the unexpected you'd need filter.resourceType to match > on the resource's supertype hierarchy too... Which is where reusing the existing script resolution logic would help, instead of reimplementing. -Bertrand
Re: Sling Request Filter "filtering"
Hi Felix, I think to reduce the unexpected you'd need filter.resourceType to match on the resource's supertype hierarchy too. Cheers, Jeff. On 18/08/2014 10:23, "Felix Meschberger" wrote: >Hi all > >I had various discussions around execution of Servlet API Filters in the >Sling Engine. > >To recap: Currently all filters are always called. The service.ranking >(or filter.order) service registration property can be used to define the >order in which the filters are called and the filter.scope property is >required to indicate at what stage in the request processing a filter has >to be called. See [1] for the full story. > >Turns out, that it would be good to have some simple and global flags to >indicate when a filter should actually be called or not. This would be >similar to the filter mappings of traditional web applications, where >filters are bound to URL paths and/or servlets. > >So I am proposing to introduce three new service registration properties, >which may be set on Servlet Filter services handled by the Sling Engine: > > * filter.path: The Filter is only called if the path of the > current Resource (SlingHttpServletRequest.getResource) > matches any of the given paths. If the property is > not set, the filter will always be called. > * filter.resourceType: The Filter is only called if the resourceType > of the current Resource (SlingHttpServletRequest.getResource) > matches any of the given resource types. If the property is > not set, the filter will always be called. > * filter.ignore: The Filter is never called if this property > is set to any "true". > > >The implementation would be as follows: > > * The FilterListEntry class is augmented with a method to verify whether >to call the filter at all > * The AbstractSlingFilterChain.doFilter method is augmented to call this >new method and to not call a filter for which the match fails. A >RequestProgressTracker entry is generated for filters not called >indicating why it has not been called. > >Further extensions could be: > > * filter.expression: some scripting expression evaluating to >a boolean. If true the filter is called. > * Filter service implements a new interface providing an filter >expression method returning a boolean. If true the filter >is called (comparable to the option servlet). > >Regards >Felix > >[1] http://sling.apache.org/documentation/the-sling-engine/filters.html
Re: Sling Request Filter "filtering"
big and fat +1 from me :) regards antonio On Aug 18, 2014, at 11:23 AM, Felix Meschberger wrote: > Hi all > > I had various discussions around execution of Servlet API Filters in the > Sling Engine. > > To recap: Currently all filters are always called. The service.ranking (or > filter.order) service registration property can be used to define the order > in which the filters are called and the filter.scope property is required to > indicate at what stage in the request processing a filter has to be called. > See [1] for the full story. > > Turns out, that it would be good to have some simple and global flags to > indicate when a filter should actually be called or not. This would be > similar to the filter mappings of traditional web applications, where filters > are bound to URL paths and/or servlets. > > So I am proposing to introduce three new service registration properties, > which may be set on Servlet Filter services handled by the Sling Engine: > > * filter.path: The Filter is only called if the path of the > current Resource (SlingHttpServletRequest.getResource) > matches any of the given paths. If the property is > not set, the filter will always be called. > * filter.resourceType: The Filter is only called if the resourceType > of the current Resource (SlingHttpServletRequest.getResource) > matches any of the given resource types. If the property is > not set, the filter will always be called. > * filter.ignore: The Filter is never called if this property > is set to any "true". > > > The implementation would be as follows: > > * The FilterListEntry class is augmented with a method to verify whether to > call the filter at all > * The AbstractSlingFilterChain.doFilter method is augmented to call this new > method and to not call a filter for which the match fails. A > RequestProgressTracker entry is generated for filters not called indicating > why it has not been called. > > Further extensions could be: > > * filter.expression: some scripting expression evaluating to >a boolean. If true the filter is called. > * Filter service implements a new interface providing an filter >expression method returning a boolean. If true the filter >is called (comparable to the option servlet). > > Regards > Felix > > [1] http://sling.apache.org/documentation/the-sling-engine/filters.html
Re: Sling Request Filter "filtering"
Hi, On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger 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
