Building the Policy Injection in 40 Minutes with Windsor

time to read 9 min | 1647 words

David Hayden posted about the policy injection block, and he mentioned that he believe that it should be integrated into the various EntLib offerring. Since he is using Windsor already, I asked why he is not using Windsor's capabilities to do this. Apperantly, they are not well publicized, since he wasn't aware of it. Therefor, I decided to take a look at what it would take to implement the Policy Injection capabilities with Windsor.

It took me about 40 minutes and 400 lines of code.

I didn't look at the Policy Injection code, or most of its documentation, I just read David's post and used that as a spec.

The end result is that you can add this to your windsor configuration, and you will get this functionality.

<facility id="policy-injection"

                type="Windsor.Interception.PolicyFacility, Windsor.Interception">

       <policy name="logMethodsWhoseNameIsReturn">


                     <rule type="Windsor.Interception.NameMatchingMethodRule, Windsor.Interception"




type="Windsor.Interception.LoggingMethodCallHanlder, Windsor.Interception"/>




In this case, what we specify is that any method that is named return would be logged. The client code is:

IWindsorContainer container = new WindsorContainer("windsor.config");

IOrder order = container.Resolve<IOrder>();


Note that Windsor already contains similar functionality that you can enable, my purpose here was simply to demonstrante how it can be done. I left plenty of extention points in the code, specifically, you can extend AbstractMethodMatchingRule to decide which methods would be intercepted, and you can extend EmptyHandler to decided how to handle the before, after and in the case of an error.

This is fully integrated with Windsor, so you get policy injection and dependency injection (as well as any other goodies that you want).

You can get the source here.