Thanks Jason! i created https://issues.apache.org/jira/browse/SLING-7759 with more details.
I disagree with the potential issues you're mentioning: 1. today either your filter hampers *all* your requests while it should not, either you added a test at the beginning of it. So this improvement would either make your requests faster, either make your code cleaner. But shipping a test from a filter that uses it, to sling filter implementations will not slow down things. 2. right now, stack trace are reaching height you've never seen before, making troubleshooting for any request base processing more & more complex. This change is humbly going to decrease them a bit, as some filters will just not be in the chain. I'd add some DEBUG logs though, so you know why a filter is not picked up Le ven. 29 juin 2018 à 17:13, Jason E Bailey <[email protected]> a écrit : > I think adding one or request method makes a lot of sense, I'm fine with > the thought of selectors as well. > > Potential issues I could see: > 1. Any additional filtering criteria could add more time to the request. > 2. It potentially makes troubleshooting issues more difficult as it would > be harder to determine what filter was in play > > However all of those points equally apply to the sling.filter.pattern > which is already there. Overall my thoughts are > > +1 > > - Jason > > On Thu, Jun 28, 2018, at 5:11 AM, Nicolas Peltier wrote: > > Hi, > > > > in continuation with sling.filter.pattern that makes filter chains > shorter, > > and code cleaner, could we add selector and request method for scoping > in & > > out filters? > > > > Nicolas >
