LightWire Version 0.01 released!

I've just upgraded LightWire (from version 0.001) to support proper constructor, setter and (the newly defined) mixin injection methods. It handles circular dependencies in all three (or any combination of them), provides lazy loading and has a very simple to use programmatic config file. It is also optimized to inject dependencies into transients as well as singletons and at under 300 lines of code, there is only so much that can go wrong :->

If you’re looking to better understand how Dependency Injection/Inversion of Control works, at under three hundred lines of code it makes perfect sense to at least check out LightWire to see one way to implement a simple DI engine. If you’re just looking for a DI engine off the shelf to solve a problem, I‘ve outlined some of the strengths of LightWire as well as the outstanding priority enhancements and outstanding issues that are less of a priority to give a sense of the current state of play of the LightWire experiment.

Current Features Base class path – Instead of having to enter the full class path for every bean, you can create a single base class path to prepend all bean class paths with. This makes it easier to reuse configuration information between different applications with different mappings as only one property needs to be changed – not one per bean.
Programmatic configuration file – If you have multiple similar configurations, you can use the full power of a programming language to programmatically set those configuration properties. You still have the ability to use multiple config files, but you don’t have to have multiple config files where a few if statements will do the same job without you having to repeat changes (such as additions of new bean definitions) in multiple files.
Mixin Injection - Mixin injection provides the benefits of setter injection (supporting the resolution of circular dependencies) without “messing up” your bean APIs by requiring set%ObjectName%() methods for injecting the objects. LightWire still supports constructor injection (recommended) and setter injection (where you need it).

Priority Improvements AOP - I consider AOP as an essential feature for a DI engine and will be adding an implementation within the month. It will be based on the Spring approach, but simplified where possible.
Custom bean factories - LightWire is already optimized for creating transients, and I want to make it session aware a la Spring 2.0. I want to provide a range of value added features to any custom bean factory support, but I’m not sure exactly how to implement this. Expect custom bean factory support some time this year as soon as I can figure out the most valuable way to implement them. Any thoughts on approaches or features seriously appreciated.

Outstanding Issues
These are items I could address but that aren’t a priority for my use case, so they won’t get added until there is a demand for them. If you like LightWire but any of these are a deal killer for you, drop me a line and let me know!
XML Config - I honestly prefer the flexibility of a programmatic configuration file, but might add support for a subset of the Spring DTD if it made sense to do so.
Auto wiring - I really don’t like autowiring. I’m concerned with transients that there is a real possibility of naming conflicts in larger projects (properties which have the same name as a bean and get the bean setter injected by accident). I also really like my LightWire config file to tell me what beans depend on what other ones as that is extremely useful information. Because of this it is extremely unlikely that LightWire will ever support autowiring. On the upside, the extra work of mentioning the bean dependencies is mitigated by the fact that you just have to provide a comma delimited list, not a bunch of XML, and if you use mixin instead of setter injection you can get rid of a bunch of setter methods which would otherwise be messing up the API of those beans, so I’m thinking on balance the amount of typing comes out about even and I feel that the LightWire approach gives you a much clearer picture of your application as the config file fully describes all dependencies. I’m always open to persuasion, but am less open on autowiring than on most other things.

Of course LightWire is very early stage, so I wouldn’t use it on a production project just yet and there isn’t much in the way of a support group or community. Documentation is also very sparse, but if anyone finds this to be of any use, let me know and I can work up some more docs and other resources!