LightWire or ColdSpring?

Below is my response. Any clarifications or refinements appreciated. Flames tolerated, but it'd be nice if we could have a logical, balanced, framework comparison between grown ups - just this once.

In particular, any additional benefits of ColdSpring that I've missed, I'd appreciate if you could add in the comments.

Well, I just posted a couple of entries:

http://www.pbell.com/index.cfm/2007/4/5/LightWire-The-Benefits-of-a-Programmable-Configuration-Object

http://www.pbell.com/index.cfm/2007/4/5/LightWire-Why-I-Love-Mixin-Injections

Here are some thoughts: ColdSpring is much more widely used. It has been out there longer. It has better documentation. It is solid, works well and there are a good community of users. It is also the only game in town (at the moment) if you want AOP or automagic remote bean proxies.

Two minor LW considerations:

LightWire is smaller (two files) so if you happen to want to drop it into a project, you don’t need to add a mapping and a whole other dependency – you just add two files plus your config.

LightWire is simpler – if you want to know HOW a DI engine works, the core code in LightWire is under 400 lines so it is a great way to look under the hood and really get the pattern.

Three bigger ones:
1. DI Into Transients: LightWire is OPTIMIZED for DI into transients as well as singletons. You CAN DI into transients using ColdSpring, but every time I asked, I was told it was not recommended. So if you want to do a lot of User.save() where you put UserDAO within the User object, at least look at LightWire as that is what it was build for.

2. Programmatic Config: LightWire uses a programmatic config. Programmatic configs vs. XML is pretty much a religious war. All I will say is that there are clearly benefits to both approaches depending on your use cases (there are seldom wars between a smart approach and a consistently useless and stupid one) so if you want a programmatic config file, feel free to check out LightWire.
3. Mixin injection: See the second link above, but basically this is a third type of DI in addition to constructor and setter injection (which LightWire also supports). In my opinion it allows for the benefit of setter injection (handling circular dependencies) without having to add a bunch of setter methods to your classes just to make your DI work. I love the approach, but it is not a widespread solution (I haven’t noticed it in any other DI frameworks in any languages, although I may have missed it).

Please also note that unlike ColdSpring, LightWire does not support auto-wiring. I’d rather have a single definitive config file and use mixin injection to cut down on all of the spurious setter methods, but if you like auto-wiring, you won’t see it in LightWire – now or in the future.

I would recommend if you are interested in DI into transients, programmatic config or mixin injection you should check out LightWire. Otherwise, unless the small size or the learning benefits are of interest, I’d say ColdSpring is still the default choice.

Best Wishes, Peter