On Tue, Sep 8, 2009 at 3:43 PM, Jeremy Haile <[email protected]> wrote: > It is confusing for me to discuss how Shiro's configuration should be > overhauled, because there are different types of configuration that are > suited to different configuration mechanisms. I think in order to have an > effective discussion about overhauling the configuration, we need to break > these down.
Whatever mechanism(s) we choose, I feel they should all be in the same physical file (or single block of text). I wouldn't want end-users to specify multiple files - that would be an inconvenience that I at least would like to avoid as an end user. > #1 Properties > Currently Shiro treats properties the same as objects and essentially has a > "poor man's" IoC framework for injecting these. The problem is that > sometimes these properties need to be used deep in the hierarchy, resulting > in either ugly nested property names or "pass through" property code which > is equally ugly and strange. (see > DefaultWebSecurityManager.setRememberMeCookiePath() and > WebRememberMeManager.setCookiePath() for an example) > > I think the best solution here is to introduce a true properties file that > would be available (somehow) to anyone no matter how deep they are in the > hierarchy. This would essentially define defaults that could be used by > internal classes without having to pass the variables deep into the > hierarchy. I don't know how to support this cleanly - there could be tons of properties to support and we'd still have to find a way to define them and then set those values on the underlying objects. Would we be required then to use a 'pull' model, where our classes need to know how to acquire these values themselves? I don't particularly like that model - all of our classes are configuration agnostic, which is very nice. Maybe some mediator that would know how to apply configured values... > #2 Defining realms, filters, and overriding default implementations > Currently this is done with the "poor man's" IoC implementation as well. At > this level I think we should support using several IoC frameworks but NOT > WRITE OUR OWN. Support Guice out of the box for this. Support Spring out > of the box for this. Support programmatically doing this out of the box. > But if you want to use IoC - dang it, use one that already exists. We've already done this with our .ini mechanism, but it falls short in a few key areas. This is something I was looking to Groovy for - to 'pick up the slack' so to speak. Not a full blown IoC container, but still useful while remaining simple. Using Groovy could allow us to do other things as well - it'd be easy to config urls and 'global' properties in #1 using Groovy syntax, given how nice it is for custom Domain Specific Languages. > #3 Declarative URL security > Currently this is declared in INI format either in the web.xml file or in a > shiro.ini file. I think this actually still makes sense. Alternatively it > could be injected directly into the ShiroFilter (if you are using an IoC > container. See my thoughts above on groovy-based configuration - it can handle declarative security just fine and would still be easy to read. But I wonder - should our default Lowest Common Denominator configuration mechanism have _zero_ dependencies? Currently we don't even meet that criteria - our .ini mechanism requires Commons BeanUtils, and I haven't heard anyone complain about that as a dependency. If we went the Groovy config-based approach, we'd just swap out the BeanUtils dependency for the groovy .jar. Seems like a fair trade-off for the additional benefits it would provide. Thoughts? - Les
