A Spring in NHibernate’s Conversation per Business Transaction

In my last post on CpBT (Conversation per Business Transaction) I have used Castle AOP. In uNhAddIns you can find examples, of CpBT usage, in WinForm, Castle.MonoRail and an introduction example for WCF (thanks to Gustavo Ringel and Alexander Surin).

The news is that now you can use the same code with Spring.AOP.

uNhAddIns.SpringAdapters

I’m not an expert with Spring and frankly was not so easy to find the better way to implements “all” classes needed. The mayor difficult was only the fact that Spring has a lot of very interesting features and the API is really fine-grained. You can obtain similar results in different ways. Erich Eichinger point me in various places of Spring's documentation before find all needed to completely reuse uNhAddIns.Adapters.Common.

Inheriting from AbstractConversationInterceptor the interceptor it self, the implementation for Spring and Castle, is not a big deal. My problem was only find the better way to wire the proxy factory to my interceptor; when I find it, between AutoProxyCreators, Advisor, Advise, custom ProxyFactory and so on, the result was very very simple:

public class ConversationalAttributeAutoProxyCreator : AbstractFilteringAutoProxyCreator
{
private readonly ReflectionConversationalMetaInfoStore store;

public ConversationalAttributeAutoProxyCreator(IConversationalMetaInfoStore store)
{
  this.store = (ReflectionConversationalMetaInfoStore)store;
}

protected override bool IsEligibleForProxying(Type objType, string name)
{
  if (store.GetMetadataFor(objType) == null)
  {
      return store.Add(objType);
  }
  return true;
}
}

As you can see… was trivial (Erich Eichinger said me: “no worries, once you get it, it is quite easy”).

The Spring configuration

Before look for “Spring programmatic configuration” I ask a link to Erich and he said :”you are just hitting our Achilles heel; programmatic conf. is not so nice ”.

In uNhAddIns.Adapters.CommonTests there are some common tests for CpBT AOP; there I’m using CommonServiceLocator and some abstract methods to configure the test for a specific IoC/AOP framework.

Well… this is the implementation using Spring’s programmatic configuration:

protected overrideIServiceLocator NewServiceLocator()
{
    IConfigurableApplicationContext context = newStaticApplicationContext();
    var objectFactory = context.ObjectFactory;
    objectFactory.RegisterInstance<ISpringConfigurationAccessor>(newTestSpringConfigurationAccessor(objectFactory));

    objectFactory.RegisterDefaultConversationAop();

    // Services for this test
   var sl = newSpringServiceLocatorAdapter(objectFactory);

    objectFactory.RegisterInstance<IServiceLocator>(sl);

    objectFactory.Register<IConversationContainer, ThreadLocalConversationContainerStub>();

  objectFactory.Register<IConversationsContainerAccessor,ConversationsContainerAccessorStub>();

    objectFactory.Register<IDaoFactory, DaoFactoryStub>();

    objectFactory.Register<ISillyDao, SillyDaoStub>();

    return sl;
}

protected override voidRegisterAsTransient<TService, TImplementor>(IServiceLocator serviceLocator)
{
    var ca = serviceLocator.GetInstance<ISpringConfigurationAccessor>();
    ca.ObjectFactory.RegisterPrototype<TService, TImplementor>();
}

protected override voidRegisterInstanceForService<T>(IServiceLocator serviceLocator, T instance)
{
    var ca = serviceLocator.GetInstance<ISpringConfigurationAccessor>();
    ca.ObjectFactory.RegisterInstance(instance);
}

Really, I don’t understand why Erich said that the “programmatic conf. is not so nice”; I can’t see anything so nasty, do you ? ;)