Absolutely not Spring. Don't get me wrong, I've used and currently use Spring in many many projects, but it's a heavy-weight and still doesn't match core feature-wise with the latest in IoC, guice and tapestry-ioc. Yes, it'll be a tough call - I can see there's a quite a bit of boilerplate code in Shiro that would just go away if it was using an IoC container, but at the same time if the project has gone this far without it, why introduce a new dependency now? Pico, Guice and tapestry-ioc should all be included in the evaluation together with Spring if one must be chosen, but I tend to agree with Brian - the optional packages could fill the void even if the default configuration scheme doesn't offer it all.
Kalle On Fri, Sep 4, 2009 at 9:13 AM, Brian Demers<[email protected]> wrote: > 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 >> >
