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 >
