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