Home Contact

Rob Kitson

"Anyone who has never made a mistake has never tried anything new." -Albert Einstein

My First OSS Contribution

Tonight I made my fist contribution to an open source project.  And it feels good to know that I've helped in some way/shape/form.

I decided that today would be a good day to check out Castle Windsor, and try to get a better understanding about how I can leverage this whole IoC thing in some of my projects.  As is my style when starting to play with a new project, framework, technique, piece of software, or well just about anything new, I put it through it's paces. 

So, I setup a test project which uses IoC and Castle Windsor as a container and everything was going fine.  I basically followed the Getting Started instructions on the CastleProject site and everything went fine, until I started monkeying with it.  It states in a few places (the example and the documentation) on the site that if you have multiple implementations of the same service, the first one that is registered with the container becomes the default for that service (a.k.a. component).  With that in mind, I started playing with the order that the IFailureNotifier components were being added to the container just to make sure that it was truly a FIDO (First In Default Out) situation.

The first time I tried playing with the order was during the step where you are adding the components to the container programmatically, and it didn't work.  No matter what order I put the components into the container, the EmailFailureNotifier was injected into the HttpServiceWatcher.  After playing around a bit without success, I moved on to the 'Using the configuration file' section to see if initializing the container from a config file would present some different behavior.  No such luck. 

Was I doing something wrong?  Was this a bug?  Was the tutorial missing something?
No.  As it turns out, it was a bug.  And after bringing it the the attention of the powers that be, it got fixed tonight.  Which means it's not in RC3, but it is in the repository and will be out with the next release/RC. 

There is a workaround.  If you are using the xml configuration, all you have to do is use a service override to explicitly declare the implementation that a component is dependent on.  In the configuration file you would use a service lookup for the property, or constructor argument, where you wanted to ensure it used a specific component.  I haven't looked into how this would be done programmatically yet.  Maybe Ayende will catch this post and drop a hint in the comments, or maybe I'll figure it out tomorrow and beat him to it.  Oh the suspense.

So there you go, my first contribution to an open source project is finding a bug... and I thought it was going to be some sort of documentation as I start digging in and learning these systems.

Feedback

# re: My First OSS Contribution

Programmatically it is something like:

IConfiguration parameters = new MutableConfiguration("parameters");
parameters["notifier"] = "#{email}";
kernel.GetHandler("watcher").ComponentModel.Configuration.AddChild(parameters);

Blog code from memory, so there may be some mistakes, but that is the general idea. 12/7/2007 6:30 AM | Ayende Rahien

# re: My First OSS Contribution

I just hit that bug with a client last week - right pain to track down it was too (mostly because I was trying to diagnose there issue over the phone).

Good to see it's been sorted :) 12/13/2007 2:52 AM | Alex Henderson

Post a comment
Not Displayed
 
Please add 6 and 5 and type the answer here: