On Thu, Feb 10, 2011 at 5:48 PM, Les Hazlewood <[email protected]> wrote: > 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?
Perhaps I didn't explain the issue properly, but re-read the issue description again. Since the path specific configuration is the only actual attribute of the filter, it should be part of each specific filter instance. If we just created a separate filter instance for each chain, it'd simplify the logic, make it perform better and divide the responsibilities better. Kalle
