Scheduling to 2.0 initially as this might be disruptive.
Currently, to receive the benefits of the NameableFilter, OncePerRequestFilter, PathMatchingFilter, etc, a user must subclass one of these classes. It would be better to have a proxy of sorts that performs these functions for any filter and wraps the 'real' target filter. This way, users' filter implementations do not need to be tightly coupled to Shiro's API. This will also enable these features for already existing filters so they don't need to be refactored to subclass a Shiro class.