As it currently stands (at least until 2.0), I don't believe this is possible.
PathMatchingFilter does more with the paths beyond just seeing if it should execute. It uses the configured paths to determine path-specific configuration as well as support the isFilterChainContinued method (which allows inspection of path-specific config). Being able to dynamically react to path-specific configuration during a request is a big feature of many of the Shiro filters, as well as many custom subclasses out of our control. Just out of curiosity, what is the push to refactor the hierarchy? While I agree that we might do well to favor composition over inheritance and clean things up, what is the _practical_ need to do this that is causing real problems for end users? Changing something fairly core to the project because it is broken I understand. Changing it when it is not broken but we think it will be better (and the risk of backwards incompatibility) is very dangerous IMO. Also, note that any out-of-the-box filter can work in Shiro's path-matching filter chain functionality. If people don't like the current hierarchy or prefer not to use it (for whatever reason), they can just implement the Filter interface directly (or use their own class hierarchy) and just plug that right in with no problems. I'm not opposed to changes. Changes can be really great. But changes for things that may not be broken and would cause backwards-incompatibility are not a good idea (generally) IMO. Thoughts? Best, Les
