I'd like some help deciding something critical to configuration and how Shiro is used in any web environnment:
Currently the ShiroFilter delegates to a WebConfiguration instance to build the SecurityManager instance. My latest (not committed) WebConfiguration interface also returns a FilterChainResolver instance that has one method: FilterChain getFilterChain(ServletRequest request, ServletResponse response, FilterChain original); The ShiroFilter uses this at runtime to determine exactly which FilterChain to execute. At this point the WebConfiguration class is essentially working just like the ShiroFilter originally worked: It takes in some configuration values and spits out a SecurityManager instance (and now a FilterChainResolver). This leads me to believe that the WebConfiguration is no different than a normal Filter in function, but now we've added an additional class that still needs to know about a FilterConfig. I feel like we've duplicated things unnecessarily. Wouldn't it make more sense then to have ShiroFilter subclasses that perform configuration-specific activities instead of complicating things with this 'WebConfiguration' concept? That is, IniShiroFilter (ini-specific config), GroovyShiroFilter, SpringShiroFilter, GuiceShiroFilter, etc. This is one case where I think inheritance might be a better choice than composition because in a composition model, the delegate object (WebConfiguration) still has to do everything a normal filter would - why duplicate the logic? Thoughts? - Les
