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 > >> > > >> > >> >
