Dexter, Datetime, Jquery, Json, Wcf, Asp net mvc, Blog engine, Javascript, Wcf service, Castle windsor, Configuration, File, Silverlight, Xml, Dynamicproxy, Multiple, Proceed

When a version of Castle Windsor able to run in Silverlight was released I started to play with it, basically because I have a lot of code that use it inside my line of business infrastructure framework. I’m working on a WPF/Silverlight solution and I’ve developed a framework that work in both the environments.

One of the biggest thing I miss in every ‘Silverlight-enables’ IoC system I tried is the ability to read and parse XML configuration files.

The current release does not allow Silverlight to parse XML configuration file, because all the parser is based on classes that are in the System.Xml namespace and that weren’t included in the Silverlight runtime.

The good news is Silverlight has a very good support for Linq To Xml, so I decided to do a ‘test of feasibility’ and switched the current implementation from using the XmlDom to Linq To Xml.

I have to admit it was more complex than I thought at start (mainly because I had to understand how the parser was written), here are the steps I followed:

1. Download the ‘Inversion of control’ portion the Castle Windsor trunk an check the project to find the classes to modify: the good news is: all of them are inside a single folder ‘Castle.Windsor\Configuration\Interpreters’
2. Start with the .Net solution and replace the usages of the ‘old’ XmlDom classes (XmlDocument, XmlNode, etc...) with the new one from System.Xml.Linq (XDocument, XElement, XNode...). Beware it’s not that easy!
   Both these systems act in slightly and sometime subtle different ways so I had to make ‘heavy’ modifications to all the class of the parser.
3. Keep modifying and fixing the XmlInterpreter and all the other classes until all the tests for the .Net solution pass. At this stage the major modification were the introduction of a LinqToXmlConfigurationDeserializer to replace the standard one and a LinqExtensions class that contains extensions methods to mimic functionalities present in System.Xml.* classes and not directly exposed by Linq classes.
4. Open up the Silverlight solution, include the new files and verifies it compiles...here some more minor modification were needed to exclude a couple of portions of code that really aren’t available in Silverlight.
   Good! It compiles!
5. Let’s see an overview of all the files that were modified:
   All the files we touched are inside the Configuration/Interpreters folders, no other section was modified.
6. Let’s create a very simple Silverlight Test Application and check it on the ‘Field of Glory’:

   [TestClass]

   public class Tests

   {

       private string config = "<configuration><components>" +

                               "<component id=\"child\" " +

                                          "service=\"SilverlightTest.Domain.IChild, SilverlightTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\" " +

                                          "type=\"SilverlightTest.Domain.Child, SilverlightTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\" />" +

                               "<component id=\"parent\" " +

                                          "service=\"SilverlightTest.Domain.IParent, SilverlightTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\" " +

                                          "type=\"SilverlightTest.Domain.Parent, SilverlightTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\" />" +

                               "</components></configuration>";

       [TestMethod]

       public void ComponentRegistrationString()

       {

           WindsorContainer container = new WindsorContainer(new XmlInterpreter(new StaticContentResource(config)));

           // resolve the object

           IParent p = container.Resolve<IParent>();

           Assert.IsNotNull(p);

           Assert.IsInstanceOfType(p, typeof(Parent));

           Assert.IsNotNull(p.ChildConstructorDependency);

           Assert.IsInstanceOfType(p.ChildConstructorDependency, typeof(Child));

           Assert.IsNotNull(p.ChildProperty);

           Assert.IsInstanceOfType(p.ChildProperty, typeof(Child));

       }

   }

and let’s run it:

Cool! It works: you can now feed up the configuration even from an XML file to the Silverlight version of Castle Windsor too (you can his file from a database a web service or download it directly..that’s up to you).

What’s left to do: as I said before this whole thing started as an experiment and the code is not clean, not optimized nor checked for memory leaks. Plus actually I modified the parser classes and ‘lost’ the previous implementation (I was lazy and I didn’t wanted to write some new tests...I just reused the old ones :D). Some more work is needed to create a full new implementation (parallel to the old one) and write some additional tests for it.

Actually I see only a potential problem and that is how to deal with configuration file inclusion: we should be able to inject an external handler that tells to the processor how to retrieve the resource (we cannot have access to physical files directly (except for those on the Isolated Storage)...so this feature still need some more thinking.

Plus the actual code it’s not very clean and contains a couple of hacks I’m not very proud of and would like to get rid of :D

I think that a good move can be to create a new ‘Castle.Windsor.Configuration’ project and move the configuration code there.

Here is the full source code of this sample if you want to download and try it, it contains the full trunk portion of the Inversion Of Control section in Castle Windsor:

I will submit this code to the Castle Dev Team and see what they think about it.

This entry was posted on Friday, 22 January, 2010 and is filed under Castle Windsor  Silverlight . You can follow any responses to this entry through here . You can leave a response.

This is a typical scenario: you have a remote service (a database a web service...anything) which can have connection problems; obviously you don’t want your application to crash the desired behavior can be to retry the operation for a couple of times and then ask the user what to do (with a message box maybe).

Implementing this in Spring.Net is quite easy, here is some ugly code that build up a skeleton for the feature:

[System.CLSCompliant(false)]

public class ExceptionHandlerDaoAroundAdvice : IMethodInterceptor

{

    public object Invoke(IMethodInvocation invocation)

    {

        // endless loop to let the user retry the operation in case of db error

        int tries = 0;

        while (true) {

            try {

                tries += 1;

                object o = invocation.Proceed();

                return o;

            }

            catch (SqlClient.SqlException ex) {

                HandleDbException(ex, tries);

            }

            catch (NHibernate.ADOException ex) {

                HandleDbException(ex, tries);

            }

        }

    }

    // log the error and ask user if they want to retry, if not abort program

    private void HandleDbException(Exception ex, int tries)

    {

        // examine the exception and

        // in case of connection problems

        // use your session or connection manager to close any pending connection, thay are not valid anymore;

        if (tries < 4) {

            // let's wait a bit before retry

            Threading.Thread.Sleep(2000);

        }

        else {

            // todo: call here the service that have to ask the user what to do: wait more and retry,

            // contact the network administrator or close the application for example

        }

    }    

}

to wire it to a proxy generated around your object you can write something like:

ProxyFactory factory = new ProxyFactory(YOUROBJECT);

factory.AddAdvice(new ExceptionHandlerDaoAroundAdvice());

return factory.GetProxy();

But since I already use Castle Windsor as my IoC system and DynamicProxy for the lazy loading with NHibernate, in order to reduce the number of assemblies and external library my application uses, inspired by this great series of articles by Krzysztof Kozmic I decided to swap out Spring.Aop and use Castle’s Dynamic proxies.

The first implementation was more or less a plain translation of the code shown above and surprisingly I got an InvalidOperationException for calling invocation.Proceed() multiple times inside the Intercept() method of the interceptor.

To verify this I setup a simple test case with an adhoc interceptor that called invocation.Proceed() multiple times:

public interface ITestClass

{

    void TestMethod();

}

public class TestClass : ITestClass

{

    public void TestMethod()

    {

        Console.WriteLine("Test Method Called");

    }

}

public class FailingRetryInterceptor : IInterceptor

{

    #region IInterceptor Members

    public void Intercept(IInvocation invocation)

    {

        invocation.Proceed();

        // we want to call proceed multiple times to simulate maybe something

        // like retrying a connection to a database or a remote service

        // after having informed the user

        // let's try to call the proced again, we expect a big time

        // failure here cause the standard implementation does

        // not allow the proceed method to be called multiple times

        invocation.Proceed();

    }

    #endregion

}

[TestFixture]

public class InterceptorsTest

{

    readonly ProxyGenerator _generator = new ProxyGenerator();

    [Test]

    public void TestFailingRetryInterceptor()

    {

        Assert.Throws(

            typeof (InvalidOperationException),

            () =>

                {

                    ITestClass sut =

                        _generator.CreateInterfaceProxyWithTarget<ITestClass>(new TestClass(),

                                                                              new FailingRetryInterceptor());

                    sut.TestMethod();

                });

    }

}

If you run this test it passes, which means we get the InvalidOperationException. This operation is perfectly legal in Spring while it’s not allowed in Castle, to investigate the issue I got the source code for DynamicProxy and looked at the implementation of the Proceed() method inside the AbstractInvocation class:

   1: public void Proceed()

   2: {

   3:     if (interceptors == null)

   4:         // not yet fully initialized? probably, an intercepted method is called while we are being deserialized

   5:     {

   6:         InvokeMethodOnTarget();

   7:         return;

   8:     }

   9:  

  10:     execIndex++;

  11:  

  12:     if (execIndex == interceptors.Length)

  13:     {

  14:         InvokeMethodOnTarget();

  15:     }

  16:     else if (execIndex > interceptors.Length)

  17:     {

  18:         string interceptorsCount;

  19:         if (interceptors.Length > 1)

  20:         {

  21:             interceptorsCount = " each one of " + interceptors.Length + " interceptors";

  22:         }

  23:         else

  24:         {

  25:             interceptorsCount = " interceptor";

  26:         }

  27:  

  28:         var message = "This is a DynamicProxy2 error: invocation.Proceed() has been called more times than expected." +

  29:                       "This usually signifies a bug in the calling code. Make sure that" + interceptorsCount +

  30:                       " selected for this method '" + Method + "'" +

  31:                       "calls invocation.Proceed() at most once.";

  32:         throw new InvalidOperationException(message);

  33:     }

  34:     else

  35:     {

  36:         interceptors[execIndex].Intercept(this);

  37:     }

  38: }

Looking at the implementation is pretty easy to understand why we cannot call the proceed more than one time per interceptor: if we do the we increment the execIndex outside the bound of the interceptors array.

In my application I have full control over which interceptors get injected on each proxy, so a simple hack would be to allow me to reset the ‘execIndex’ variable to -1; doing this way the next time you call invocation.Proceed() from an interceptor the whole chain start from the beginning allowing you to recover and retry the operation.

I don’t like to modify the library code, cause at every update I have to reapply the path again, the Hack here is to use some reflection and write an extension method for the IInvocation interface:

public static class IInvocationExtensions

{

    private static FieldInfo _resetInvocationInterceptorsCall;

    public static void Reset(this IInvocation invocation)

    {

        if (_resetInvocationInterceptorsCall == null)

        {

            Type invoc = FindBaseType(invocation.GetType(), typeof(AbstractInvocation));

            if (invoc == null)

                throw new InvalidOperationException("IInvocationExtensions - Cannot find AbstractInvocation as base class.");

            _resetInvocationInterceptorsCall = invoc.GetField("execIndex", BindingFlags.Instance |

                                                                                              BindingFlags.NonPublic);

        }

        // reinitialize the index of execution, so when we call Proceed() again

        // the whole chain of interceptors start again from the first element

        _resetInvocationInterceptorsCall.SetValue(invocation, -1);

    }

    private static Type FindBaseType(Type src, Type lookingFor)

    {

        while (!(src == typeof(object)) && (src != lookingFor))

        {

            src = src.BaseType;

        }

        if (src == lookingFor)

            return src;

        return null;

    }

}

We can now update our test and write another interceptor that call the newly created Reset() method to allow us to recover and start the execution again:

public class SuccessRetryInterceptor : IInterceptor

{

    #region IInterceptor Members

    private bool firstcall = true;

    public void Intercept(IInvocation invocation)

    {

        invocation.Proceed();

        if (firstcall)

            {

                firstcall = false;

                // we want to call proceed multiple times to simulate maybe something

                // like retrying a connection to a database or a remote service

                // after having informed the user

                // we ask to reset the current call and start it again from the beginning of the

                // interceptors chain

                invocation.Reset();

                // let's try to call the proced again, we expect a big failure here cause the standard implementation does

                // not allow the proceed method to be called multiple times

                invocation.Proceed();

                // note that in this test we used the firstcall variable to stop the recursive calls

                // of this interceptor.

            }

    }

    #endregion

}

[TestFixture]

public class InterceptorsTest

{

    readonly ProxyGenerator _generator = new ProxyGenerator();

    [Test]

    public void TestSuccessRetryInterceptor()

    {

        Assert.DoesNotThrow(() =>

        {

            ITestClass sut = _generator.CreateInterfaceProxyWithTarget<ITestClass>(new TestClass(), new SuccessRetryInterceptor());

            sut.TestMethod();

        });

    }

}

If you execute this test you can see that it passes and that the TestMethod() of the test class gets called two times.

BEWARE! This is a dangerous technique and you have to be absolutely aware of what you are doing, cause you are executing the whole interceptors’ chain from the beginning..so if some of your interceptors modify the data or perform some advanced operations you have to know exactly what they do in order to not alter/invalidate the data of your application.

This entry was posted on Tuesday, 19 January, 2010 and is filed under Castle Windsor  Dirty Tricks . You can follow any responses to this entry through here . You can leave a response.