My Spring suggestion might have been too specific of a reference - I only really care about lifecycle management and a declarative mechanism (XML, YAML, etc) that suits object graph definitions and handles lifecycle management well - and ideally one that we wouldn't have to support from scratch.
Our current .ini mechanism fails quickly when it comes to lifecycle management. We'd have to write code to support that and probably change the format to be something like a subset of the Velocity Template Language (VTL) to support these more complicated mechanisms. This all translates into things that we would have to code, and we'd essentially be re-inventing the wheel. And it would be non-standard and yet-another-format that end-users would have to learn, which I would love to avoid. I just wanted to explore other possibilities before we go down a potentially time-consuming road and perhaps use another tool that is well suited for the job. If we just have to 'suck it up' and roll our own to guarantee a lowest common denominator for all of our users, then so be it. But I'd only like to do that if everyone feels we must ;) Any suggestions on what should be the default, either our own or some other mechanism? - Les On Fri, Sep 4, 2009 at 12:29 PM, Kalle Korhonen <[email protected]> wrote: > 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 >>> >> >
