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 <[email protected]> wrote: > Hi > > Am 18.08.2014 um 12:08 schrieb Jeff Young <[email protected]>: > > > 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" <[email protected]> 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 > > > >
