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

Reply via email to