Hi Oliver, On 10 Jan 2011, at 18:32, Oliver Geisser wrote:
> Hi, > > you asked for feedback. Yes! Thanks. And sorry to the slow answer. > > Tapestry IOC > Pro: > + Proven IOC Container for "modules" > + Only IOC container with built-in "distributed configuration" support > > Cons: > - Subproject of Tapestry (but can be used stand-alone) > - Mostly a one-man-show (Joward Lewis Shipp) hmm, the plus-points are interesting indeed, worth taking a look at. TBH, I didn't even know it was usable outside the context of Tapestry-the-web-framework, so I didn't even consider it. > CDI > Pro: > + "Official" Java standard > + Multiple implementations > > Cons: > - maybe not "lightweigth" enough Jesus, how did I forget this ? Yes. The JSR-299 was only vaguely starting back when I started investigating ioc-for-magnolia and I completely lost sight of it. (I like the renaming from "web beans", which is horrible name, but hijacking another acronym which so far meant "Constructor Dependency Injection" .. ? what were they thinking?) There's another JSR of interest: JSR-330. It's just a few injection-related annotations. Turns out Picocontainer 3 will implement JSR-330. It hasn't been released yet because they want to be fully compliant (they're at about 80% of the TCK right now). There are a few things in JSR-299 that make me cringe, but probably not worth fretting about (the .enterprise subpackage names, for example). It seems a little too "complicated" for us at the moment. As users of dependency injection, in 95% of the cases, all we need are "singletons". (of course the remaining 5% are the hard-to-crack nut) > BTW > Just curious: what do you mean with "lightweigth"? > Programming model, size of JAR file, dependecies, etc.? All of the above. > Because if you just the "core" of Spring I can't see why it is not considered > as "lightweigth"? > Especially if you use a "annotation driven" configuration (which you will do > I assume). My main gripe with Spring is that it tries to do everything and the coffee. (and it succeeds in doing so, mostly) It's probably psychological, but I see Spring like quicksand - once you put a foot in it, you're sucked into it ;) Anyway, here's my plan for now: * get a working Magnolia using Picocontainer (because that's the only of all the above containers I know), and stay as far as possible from pico-specific stuff. (i.e wrap as much as possible either in one of the JSR above, or in our own interfaces). I don't really intend to make it possible to swap to another container transparently (lots of work for no real benefit ?), but simply to avoid container-specificities to creep in our code. * re-evaluate all other possibilities, see if/how they would fit the above proof-of-concept * make a final decision. TBH, I'd currently probably be in favor of Guice, simply because it is more widely known. But so far, Tobias and I have a hard time understanding how it works, as we're both used to the concept of a container for IoC, and Guice doesn't explicitly use that concept (although I suspect it IS there) Cheers, and thanks for all and any further comment, -greg > 2011/1/10 Grégory Joseph <[email protected]> > > Hi list, > > Tobias and I just had a first meeting about an old issue we've been wanting > to tackle for a while: IoC in Magnolia. If this means nothing to you, perhaps > this reference will help: > http://wiki.magnolia-cms.com/display/DEV/Concept+IOC+in+Magnolia > > We're going to branch the trunk and experiment a little, hoping to > demonstrate the following: > * feasibility and backwards compatibility - get a feel of how much work it > means for core, and get a feel of the impact on modules. Ideally, we want > modules to be 100% compatible (good practices will come naturally, or so we > hope) > * demonstrate basic DI mechanisms (perhaps via a model in the sample > modules), configuration properties resolution, and impacts on content2bean. > * how modules can contribute objects/components (and perhaps associated > factories) > > We'll be evaluating PicoContainer and Guice for this; if you have other > suggestions, please chime in! (only constraint: we want something > ultra-lightweight, sorry Spring fans;)) > > Cheers, > > -g > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > > > > -- > og > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
