ColdSpring is an amazing and popular DI/IoC framework used by most OO ColdFusion developers. LightWire is a lightweight DI framework that solves a similar set of problems (it doesn't yet have AOP or remote bean creation and provides only a subset of the functionality of ColdSpring).
So, why would you bother looking at LightWire when you already have ColdSpring?
Two reasons: programmatic configuration and Dependency Injection for transient objects.
There are many benefits to XML config files but if you look in the Java world you will see a lot of debate from Spring to Ant about using programmatic rather than XML config files. A later version of LightWire will include support for a subset of the ColdSpring XML dialect so you will be able to port more seamlessly from ColdSpring to LightWire, but the core configuration mechanism for LightWire is programmatic. There is a whole debate to be had over the benefits of programmatic vs. the benefits of XML config files, but it is kind of moot if the only CF DI engine doesn’t support programmatic configuration. Now there is an alternative for the use cases better served with programmatic configuration and for developers who just prefer that approach.
I know that Dave Ross is a big fan of service layers with relatively "dumb" business objects acting as something between a TO and a bean. That is a very valid approach and extremely common in the Java world. Another equally valid approach is to put more behavior into business objects and to have much less functionality in the service layer (some developers don’t even use a service layer at all although I don’t love that approach).
I personally like to put a little more intelligence (typically using composition) into my business objects. The only problem with that is I need to be able to inject service objects into my business objects. ColdSpring allows for this. You can either create “beans” with Singleton=false or (more likely) create a custom bean factory. However, ColdSpring was not designed or optmized for this approach. It is optimized for “a service layer + transfer object approach” as that is the way Dave and Chris tend to program.
As I have recently argued there is very little difference between the two approaches (something I actually only understood when Dave Ross explained it to me at CF United). That said, I happen to prefer a more SmallTalk/Python/Ruby approach of putting more on the business objects rather than the service layer approach which is typically more common in the Java world.
LightWire was developed to scratch my internal itch, but if anyone finds any value in this, just let me know. Either way I’ll be adding AOP as I have a need for that and if anyone really wants it I’ll add the ability to read ColdSpring XML files to make it easier to try out LightWire if you’re already using ColdSpring.