Peter, does this address your concerns? Or do you feel there might be a better way still?
I'd like to make sure that we all feel as comfortable as possible on this moving forward - it essentially defines how any web-based framework would integrate w/ Shiro, so it should be pretty solid. Regards, Les On Thu, Sep 17, 2009 at 10:26 AM, Les Hazlewood <[email protected]> wrote: > On Wed, Sep 16, 2009 at 7:48 PM, Kalle Korhonen > <[email protected]> wrote: >> I would probably be able to use the FilterChainResolver > > Great - that means the 'composition over inheritance' refactoring I > did makes sense and would probably be put to good use. > >> ShiroFilter is essentially an entry point to initializing the >> system, so it makes sense that it can be customized (sub-classed, >> replaced) to the needs of particular environments, rather than adding >> another level of indirection there (that likely would still need to be >> customized). > ... >> Removing WebConfiguration completely simplifies >> the interfaces and straightens out the inheritance hierarchy. > > That's my feeling too - because WebConfiguration implementations > essentially need access to the FIlterConfig and they set-up/process > FilterChains (via the FilterChainResolver), they function almost > exactly like a servlet Filter. It is a level of indirection that > doesn't gain anything IMO. > > If others feel differently and do not prefer the hierarchy approach, > I'm definitely open to suggestions. I'd love to hear any feedback on > what might be an optimal solution. > > Thanks, > > Les >
