I don't think the default impl should be based on Spring. Maybe the default impl should just be really simple, based in an ini or some pojo or something (would be nice if the current ini config would still work). Opional packages should made available for other implementations something like shiro-config-spring, shiro-config-guice, shiro-config-etc.
Or something like that anyway (I don't like the names, i am just trying to illustrate my point) On Fri, Sep 4, 2009 at 12:01 PM, Les Hazlewood <[email protected]>wrote: > For me, the biggest thing yet to be done for 1.0 (and there's not even > a Jira issue for this yet - I'll create one asap) is a configuration > overhaul. > > I've never been happy with how tightly coupled the Configuration / > .ini mechanisms are - it is not flexible and definitely should be > overhauled. The existing .ini support falls way short for proper > object-graph (OG) configuration, which is essentially what we require. > > Also since Shiro can be used in any environment, we need something > that fully supports standalone configuration, configuration in JEE > environments, and embedded web.xml configuration cleanly and easily. > Since we're essentially configuring an OG, we came to a consensus a > while ago that .ini is probably not the right tool for the job and > that we should probably be using something else. There was consensus > that YAML was at the least a better choice than .ini. > > With YAML however, we still have to write our own lifecycle management > - you essentially need init/destroy method support (and maybe > start/stop support - I dunno yet), as well as circular dependency > checks and similar OG issues. Things that have been solved elsewhere > (e.g. Spring), that we would have to re-invent. > > So the question is - we'll probably need to depend on a 3rd party > library (or set of libraries) for nice OG definition support. What > library/libraries should that be? > > Do we want to go through the effort of supporting OG/lifecycle > concerns and rolling our own using a YAML library? Seems like a lot > of unnecessary work when Spring does this all already, and very well. > But would we want to use Spring as the default configuration > mechanism? I'm _only_ talking about for initial configuration and not > suggesting that we have a required dependency on Spring or its > components at runtime. > > Its a tough call, when you think of what we may have to write from scratch. > > Thoughts? Ideas? > > Les >
