By Peter Bell

LightWire Limitation: Methods in init()s

Nothing comes for free. As Sean Corfield pointed out (scroll through the comments), the approach that allows LightWire to resolve circular dependencies using “constructor” initialization (by loading references to un-initialized beans and then initializing them in an arbitrary order) has a cost.

If your init() methods call methods on injected objects, that would fail using this approach. You can use the objects at any other time, but this approach doesn’t honor the contract of loading fully initialized beans.

Right now I don’t have a need to do this, so I’m going to enjoy the simplicity and flexibility of the current approach. If/when it becomes a problem, I’ll go back to setter injection for circular dependencies and will write the algorithm to determine the “proper” order for initializing dependent objects.

There is no perfect solution to this problem as if your beans call methods on objects they are circularly dependent on in their init() methods that is going to fail whatever you do – it is a fundamental limitation of logic. I’ll keep you posted as to how this goes.

I’d be interested to find out – do you find yourself calling a lot of methods in dependent objects as part of your init() methods?

Comments
BlogCFC was created by Raymond Camden. This blog is running version 5.005.