Question

If I register a component with the container with a name (don’t worry… contrived example!)

container.Register(Component.For<double>().Instance(Math.PI).Named("pi")

And ask to resolve that service type with a different name

container.Resolve<double>("e")

I get an ComponentNotFound exception. But now if I use the typed factory facility

interface IDoubleFactory { double GetDoubleByName(string name); }

container.Register(  
  Component.For<DoubleSelector, ITypedFactoryComponentSelector>()   
  Component.For<IDoubleFactory>().AsFactory(f => f.SelectedWith<DoubleSelector>())
  Component.For<double>().Instance(Math.PI).Named("pi"))

public class DoubleSelector : DefaultTypedFactoryComponentSelector
{
  protected override string GetComponentName(MethodInfo method, object[] arguments) 
  {
    return arguments[0] as string;
  }
}

and try to use the factory to resolve a bogus name

container.Resolve().GetDoubleByName(“e”)

I get pi back instead of an exception. It appears that having given a name to the ITypedFactoryComponentSelector which did not help, it has fallen back to just using the Type (in this case double) and grabbed the first thing registered against it.

Answer 1

The answer may be a bug in Windsor 2.5.1. The contract for ITypedFactoryComponentSelector suggests that if you return null for ComponentType but non-null for ComponentName, the lookup will be done by name, and not type. But two problems get in your way if you try to do that.

According to GitHub sources, code in DefaultTypedFactoryComponentSelector.BuildFactoryComponent calls GetCompatibleArrayItemType on what may be a null ComponentType pointer, which causes an exception. This seems like a bug, plain and simple.

If you find a way to monkey patch that, then it appears that TypedFactoryComponentResolver.Resolve method doesn’t quite arrange to call the right overloads on the kernel to resolve in cases where ComponentType is null. I’m much less clear whether this is a bug or a lack in my understanding of which IWindsorContainer.Resolve methods do what. That said, a dispatch to the various methods (Resolve<object>(string key), for example) seems to do the trick.

Both classes are unsealed, so it’s straightforward to fix with derived classes.