Ayende @ Rahien

Hi!
My name is Ayende Rahien
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

@

Posts: 5,947 | Comments: 44,540

filter by tags archive

Building the Policy Injection in 40 Minutes with Windsor


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">

              <rules>

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

                             matching-name="Return"/>

              </rules>

              <handlers>

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

              </handlers>

       </policy>

</facility>

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>();

order.Return("foo");

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.


Comments

hammett

awesome!

Chris Martin

When do you sleep man? This is killer!

Craig Neuwirt

Sounds cool! I tried to download the archive, but it seems corrupt.

craig

Ayende Rahien

Please try again with FireFox, for some reason downloads with IE are corrupted.

I'll look into it later.

Tri
Tri

Really cool! Why don't you put this facility to Castle officially?

Ayende Rahien

No one needed it, that was why it didn't exist. There are better approaches to this in the Castle world.

If you need this, it would be easier to write a facility to add the behavior yourself, no need to build a framework for this.

I'll ask in the mailing list if there is any interest in it anyway.

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. RavenDB Sharding (2):
    21 May 2015 - Adding a new shard to an existing cluster, the easy way
  2. The RavenDB Comic Strip (2):
    20 May 2015 - Part II – a team in trouble!
  3. Challenge (45):
    28 Apr 2015 - What is the meaning of this change?
  4. Interview question (2):
    30 Mar 2015 - fix the index
  5. Excerpts from the RavenDB Performance team report (20):
    20 Feb 2015 - Optimizing Compare – The circle of life (a post-mortem)
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats