Ayende @ Rahien

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

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 5,972 | Comments: 44,521

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

  1. Reducing parsing costs in RavenDB - 2 hours from now

There are posts all the way to Aug 04, 2015

RECENT SERIES

  1. Production postmortem (5):
    29 Jul 2015 - The evil licensing code
  2. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats