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üß <dominik.su...@gmail.com> 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 <jus...@justinedelson.com> > wrote: > >> Hi, >> >> On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß <dominik.su...@gmail.com> >> 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 <fmesc...@adobe.com> >> > wrote: >> > >> >> Hi >> >> >> >> Am 18.08.2014 um 12:08 schrieb Jeff Young <j...@adobe.com>: >> >> >> >> > 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" <fmesc...@adobe.com> 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 >> >> > >> >> >> >> >>
