Windsor: Component Burden described as a (bad) side effect

February 26th, 2008

This blog entry is fantastic. It explains how Windsor (well, MicroKernel) deals with non-singletons that are disposable. In the end, the author makes an interesting test:

public class DisposableCon : IDisposable {
   public ITest ITest;
   public DisposableCon(ITest iTest) {
      ITest = iTest;
   public void Dispose() {

This class simply declare a Constructor dependency, and implements IDisposable, but in the dispose does not do any stuff. The following test shows you that the container does not keeps a reference nor dispose the inner ITest object.

DisposableCon tran;
using (WindsorContainer ioc = new WindsorContainer(new XmlInterpreter(“config1.xml”))) {
   tran = ioc.Resolve(“TransientDisposableCon”);

So it is your duty to be sure that the inner objects injected by the container will be disposed correctly.

So this behavior is wrong! WRONG! You should not have to care about releasing the dependencies yourself, the container should keep track of them.

Explaining again. Suppose you have the following components:


Services depends on DependencyA, which depends on DependencyB. Let’s consider that all of them are transients.

When the “Service” is requested from the container, Windsor creates the dependencies in the bottom-top order:

1. Create DependencyB
2. Create DependencyA
3. Create Service

Service can be returned.

In an ideal world, when Service is released (container.Release(service) or container.Dispose()), Windsor needs to release all of them in the inverse order:

1. Dispose Service
2. Dispose DependencyA
3. Dispose DependencyB

DependencyA is the “burden” of Service. DependencyB is the “burden” of DependencyA. That’s what I call Component Burden. The container being able to keep track of these things that need to be release.

Of course, for 90% of the container usage, you’d use singletons, so that’s why the component burden – which is missing on Windsor and maybe on every other IoC container out there – is not missed that much. It’s only required for non-singletons components that have a decommission phase (for example, Disposable ones).

Anders has started working on this back in March of 2007. He renamed it to component responsability. The implementation wasn’t ideal, so I started reviewing it before applying. Never found the time to finish.

So, if you really want to dig into the internals of the MicroKernel, figure out an optimal strategy that will keep the “burden” only when necessary, make it beautiful, test it, license it as ASL 2.0 and send it to us, we would greatly appreciate it :-)

10 Responses to “Windsor: Component Burden described as a (bad) side effect”

Gian Maria Says:

Thanks for appreciating my blog entry, I had fun playing with castle windsor in the past, great library.


Bill Pierce Says:

What issues did you have with Anders’ implementation?

hammett Says:

I can’t remember. It wasn’t optimal for some reason…

Bill Pierce Says:

I cooked up something nearly identical but it uses Kernel.ReleasePolicy.Track rather than keeping a separate dictionary of instances/handlers.

If Anders’ wasn’t optimal then I’m guessing you wouldn’t like this anymore.

hammett Says:

Thanks for the effort, Bill. I need to finish an article for a magazine and then I’m going to dig your code.

Alkampfer’s Place » Blog Archives » Again on Castle Transient and the Custom lifecycle Says:

[...] days ago hammet link one of my old post, ( I want now to make another considerations. The end of my old post [...]

Gian Maria Says:

If you like I made a little post that shows how to solve the problem with a custom lifecycle manager, ( it could be a feasible solution, is not optimal but shows that it can be done with a lifecycle manager. I wrote the code with great speed and I hope not to made some mistake :).


hammett Says:

Cool, I’ll check it out!

The Inquisitive Coder - Davy Brion’s Blog » Blog Archive » The Component Burden Says:

[...] entire problem has been described as the Component Burden by Hammet, the original creator of the Windsor IoC container. Obviously, this is something that the [...]

Elegant Code » The Component Burden Says:

[...] entire problem has been described as the Component Burden by Hammet, the original creator of the Windsor IoC container. Obviously, this is something that the [...]

Leave a Reply