Right, agreed - that implies that the IniShiroFilter needs to be refactored to allow more flexible configuration options, so you can set your own FilterChainResolver and SecurityManager to allow it to be more 'frameworky'. Then add in some additional filter config-params to trigger common logic. Whatever is not covered by the common-logic can easily be supported by subclassing.
Perhaps an even better option is to allow end-users to configure any of these custom objects in [main] and we can 'pull' them out and apply them to the IniShiroFilter at startup. That sounds like a pretty slick option. And if end-users are anything like me (who hates configuration anything in web.xml), it sounds like a convenient approach :) Les On Thu, Feb 10, 2011 at 6:36 PM, Kalle Korhonen <[email protected]> wrote: > Try it. You cannot (currently) supply a pattern matcher of your choice > and have it propagated everywhere. PatternMatchingFilter instantiates > its own default patternMatcher that differentiates from the one used > in the resolver and there are not setters in the former. > > Kalle > > > On Thu, Feb 10, 2011 at 6:01 PM, Les Hazlewood <[email protected]> wrote: >> The only change I see for this is a PatternMatcher implementation that >> ignores case (maybe the existing class supports it via an additional >> attribute. Nothing else needs to change I don't think, right? >> >> There is probably no need to preemptively normalize/lower-case pattern >> definitions because the PatternMatcher would do that in its >> implementation. That is, it is the PatternMatcher's responsibility >> for this logic rather than the IniShiroFilter. >> >> My desire is to not permanently change the user's config in any way, >> and instead rely on logic to do it as necessary. Retaining original >> config is good IMO since we can reference it in log messages, >> exceptions, output streams, etc, without confusing the user. >> >> My .02, >> >> Les
