Castle

Some would say that it is about time, I would agree. Windsor might not be the OSS project in pre release state for the longest time (I think that the honor belong to Hurd), but it spent enough time at that state to at least deserve a honorary ... [More] mention. That was mostly because, although Windsor was production ready for the last three or four years or so, most of the people making use of it were happy to make use of the trunk version. If you will look, you won’t find Windsor 1.0, only release candidates for 1.0. As I believe I mentioned, Windsor has been production ready for a long time, and for the full release we decided to skip the 1.0 designator, which doesn’t really fit, and go directly to 2.0 The last Windsor release (RC3) was almost a year and a half ago, and in the meantime, much has improved in Windsor land. Adding upon the already superb engine and facilities, we have fitted Windsor to the 3.5 release of the .Net framework, created a full fledged fluent API to support easy configuration, allowed more granular control over the behavior of the container when selecting components and handlers and improved overall performance. All in all, pretty good stuff, even if I say so myself. Just to give you an idea, the list of changes from the previous release goes for quite a while, so I am going to let the short listing above to stand in its place. You can get the new release from the source forge site. [Less]

Some would say that it is about time, I would agree. Windsor might not be the OSS project in pre release state for the longest time (I think that the honor belong to Hurd), but it spent enough time at that state to at least deserve a honorary ... [More] mention. That was mostly because, although Windsor was production ready for the last three or four years or so, most of the people making use of it were happy to make use of the trunk version. If you will look, you won’t find Windsor 1.0, only release candidates for 1.0. As I believe I mentioned, Windsor has been production ready for a long time, and for the full release we decided to skip the 1.0 designator, which doesn’t really fit, and go directly to 2.0 The last Windsor release (RC3) was almost a year and a half ago, and in the meantime, much has improved in Windsor land. Adding upon the already superb engine and facilities, we have fitted Windsor to the 3.5 release of the .Net framework, created a full fledged fluent API to support easy configuration, allowed more granular control over the behavior of the container when selecting components and handlers and improved overall performance. All in all, pretty good stuff, even if I say so myself. Just to give you an idea, the list of changes from the previous release goes for quite a while, so I am going to let the short listing above to stand in its place. You can get the new release from the source forge site. [Less]

Some would say that it is about time, I would agree. Windsor might not be the OSS project in pre release state for the longest time (I think that the honor belong to Hurd), but it spent enough time at that state to at least deserve a honorary ... [More] mention. That was mostly because, although Windsor was production ready for the last three or four years or so, most of the people making use of it were happy to make use of the trunk version. If you will look, you won’t find Windsor 1.0, only release candidates for 1.0. As I believe I mentioned, Windsor has been production ready for a long time, and for the full release we decided to skip the 1.0 designator, which doesn’t really fit, and go directly to 2.0 The last Windsor release (RC3) was almost a year and a half ago, and in the meantime, much has improved in Windsor land. Adding upon the already superb engine and facilities, we have fitted Windsor to the 3.5 release of the .Net framework, created a full fledged fluent API to support easy configuration, allowed more granular control over the behavior of the container when selecting components and handlers and improved overall performance. All in all, pretty good stuff, even if I say so myself. Just to give you an idea, the list of changes from the previous release goes for quite a while, so I am going to let the short listing above to stand in its place. You can get the new release from the source forge site. [Less]

This question was raised on the Castle forums a couple of days ago: I have a third party dependency. It uses a property class for configuration with only a default constructor. public class Properties { public Properties() {...} public void ... [More] Add(string name, string value) {...} } I would love to be able to invoke the .Add to setup this object. Something like this: <components> <component id="Properties" type="Example.Properties, thirdParty"> <Add> <name>key1</name> <value>value1</value> </Add> <Add> <name>key2</name> <value>value2</value> </Add> </component> </components> I do realize that I could write an adapter class to interact with the Properties class and then di the adapter. But I'm wondering if I'm missing something or if there is a reason that method invocation is not supported. Windsor has so many extensibility points that sometimes I have a hard time picking the right one. Windsor lets you change, override or customize almost every aspect of its behaviour thanks to its extensible design. To solve this one, I chose to override the default component activator. The component activator is the internal service responsible for instantiating the component object. To quote Windsor's reference manual: The ComponentActivator takes a few steps to create the instance Selects the constructor it can satisfy more parameters Creates the instance using the constructor selected Tries to supply dependencies to properties Runs the commission phase lifecycle steps (if any was registered) Our custom activator will call the default activator, then "deserialize" the method calls from the configuration to the appropriate MethodInfo objects, and finally call those methods on the component instance. We can use the componentActivatorType attribute to select the custom activator. Here's a demo: [TestFixture] public class Tests { public class MyComponent { public int C { get; private set; } public void Add(int i) { C += i; } public void NoParameters() { C += 2; } } [Test] public void Init() { var c = new WindsorContainer(new XmlInterpreter(new StaticContentResource(@"<castle> <components> <component id=""mycomponent"" type=""WindsorInitConfig.Tests+MyComponent, WindsorInitConfig"" componentActivatorType=""WindsorInitConfig.InitComponentActivator, WindsorInitConfig""> <init> <Add> <i>5</i> </Add> <Add> <i>3</i> </Add> <NoParameters/> </init> </component> </components> </castle>"))); Assert.AreEqual(10, c.Resolve<MyComponent>().C); } }   You can checkout the whole code here. Note that this is not really production-quality code: it's not properly tested and it probably won't work on generic methods and overloaded methods with the same parameter names, but it's enough for most cases. Please feel free to enhance it and send me a patch! :-) [Less]

This article series deals with the internal session keeping of Castle ActiveRecord. This installment introduces the concept of a scope and how scopes are used within ActiveRecord. Introducing Scopes Having a session per database call is suboptimal. ... [More] There is no chance to use transactions, which is a showstopper for most serious uses. Another issue is lazy loading: Lazy loading prevents NHibernate from loading large collections until they are requested, avoiding to load unnecessary data. Lazy loading is however only possible when done within a single session. Castle ActiveRecord uses scopes to overcome this. A scope represents a single unit of work. It is not necessarily a single transaction, but may span multiple transactions. Prior to NHibernate 2.0, when transactions were not mandatory, scopes did not even have to support transactions. The scopes that are part of the ActiveRecord package do always share a single session that is used for all persistance related calls. However, it is possible to implement a scope that uses a new session, but the changed semantic should be clearly communicated in such a case. Localizing Scopes In order to access scopes without holding a reference to the object, they stored in thread static stacks. The central interface for this is IThreadScopeInfo, which is implemented by various classes to cover different situations such as web applications. WebThreadScopeInfo for example uses a HttpContext for storing the scopes while the default ThreadScopeInfo implementation uses a thread static field. In order to acquire the current IThreadScopeInfo implementation, ThreadScopeAccessor can be used. This class is a singleton providing the current ScopeInfo under public IThreadScopeInfo ScopeInfo Additionally it acts a proxy to this scope, delegating calls to the scope info in the property above. This allows to access the current scope without keeping a field for it using ThreadScopeAccessor.Instance.XXX(); where XXX is one of the methods defined in IThreadScopeInfo. With the IThreadScopeInfo available, the current scope can be requested by SessionFactoryHolder using the following methods: ISessionScope GetRegisteredScope() bool HasInitializedScope Scope Initialization When a scope is created, it has no sessions stored at first. That is intentional. While the ActiveRecordStarter configures the ISessionFactoryHolder at startup, it cannot configure an arbitrary number of ISessionScope implementations. Therefore the initialization of scopes is implemented using a simple protocol between ISessionFactoryHolder and ISessionScope: Upon creation, the ISessionScope registers itself with the current IThreadScopeInfo. void IThreadScopeInfo.RegisterScope(ISessionScope scope) ISessionFactoryHolder fetches the scope the next time it has to deliver a session to the ActiveRecordBase methods. bool IThreadScopeInfo.HasInitializedScope ISessionScope IThreadScopeInfo.GetRegisteredScope() The ISessionFactoryHolder asks the ISessionScope whether it already has a suitable session stored. Scopes do not hold only one session. Due to different database connections by root type, they need to hold a dictionary of sessions. The scope doesn't know the key to the sessions because the key is provided by the ISessionFactoryHolder everytime a session is required. bool ISessionScope.IsKeyKnown(object key) If there is a session registered with the scope, the session is requested and the protocol ends. ISession ISessionScope.GetSession(object key) If there is no suitable session available the ISessionFactoryHolder asks the ISessionScope whether it accepts an existing session or if it wants to create its own session. bool ISessionScope.WantsToCreateTheSession Depending on the answer to 5, the ISessionFactoryHolder either opens a session itself or provides a suitable ISessionFactory to the ISessionScope so that the session can be created by the scope itself. ISession ISessionScope.OpenSession(ISessionFactory sessionFactory, IInterceptor interceptor) The session is registered with the ISessionScope by the holder. This is done regardless who in fact created the session. void ISessionScope.RegisterSession(object key, ISession session) The freshly registered session is fetched from the scope. ISession ISessionScope.GetSession(object key) The different Scope Types Scopes generelly have two attributes that describe there behaviour: by FlushAction and by SessionScopeType. The FlushAction controls whether changes are automatically flushed to the database. The SessionScopeType describes the behaviour of the scope in common, most important whether the scope supports transactions. If the FlushAction is defined as FlushAction.Never, no writing to the database will occur unless ISessionScope.Flush() is called by the using code. This behaviour gives full control to the using code, but requires it to control flushing. This is important: If the changes are not flushed, queries will still find an older state in the database although the entity has already changed. FlushAction.Auto instructs the NHibernate session to flush its first-level-cache whenever needed. That means that if the cache contains an unflushed change to an entity, the session will write those changes back before it runs a query against the entity's type. The SessionScopeType has four values: SessionScopeType.Undefined SessionScopeType.Simple SessionScopeType.Transactional SessionScopeType.Custom Undefined should never be used; it is more an error state than a valid scope type. Simple and Transactional define whether the scope supports transactional behaviour. Custom can be used for own implementations that fall in between. An example would be a SessionScope that uses transactions only for specific sessions. The next part of the series will show how ActiveRecord usage differs when using a scope. [Less]

This article series deals with the internal session keeping of Castle ActiveRecord. It begins in explaining how sessions are managed within ActiveRecord and how the user can influence this behavior. What happens when Save() is called? The first part ... [More] of our journey starts in ActiveRecordBase. Whenever a method is called that requires a NHibernate session, it requests one from the following field: protected internal static ISessionFactoryHolder holder; Since that field is marked protected internal static, subclasses of ActiveRecordBase can directly access it to acquire a session. This is done with the following methods: ISession CreateSession(Type type); void ReleaseSession(ISession session); void FailSession(ISession session); The first method requests a session from the ISessionFactoryHolder, that can be used to issue calls to the session, such as Save(), Load() etc. After the operation was completed, ReleaseSession must be called, preferably in a finally block. If an exception is raised from NHibernate, the session cannot be used anymore. The ISessionFactoryHolder must be notified through the FailSession-method. To further understand the inner workings of ActiveRecord, we need to look at the default implementation of ISessionFactoryHolder, which is simply called SessionFactoryHolder. The SessionFactoryHolder keeps a dictionary which maps the configured ActiveRecord root types to ISessionFactory instances. Whenever CreateSession is called, it fetches the ISessionFactory for that type and creates an ISession. When ReleaseSession is called the session is flushed and disposed, closing any open connections. If you use the holder to acquire sessions directly, keep in mind that it is necessary to release them or you will get a resource leak. Database sessions are among the most critical resources with regard to leaks. If an exception is raised, the FailSession method will clear the session so that it doesn't throw again when the session is released. When ActiveRecord is used without any scopes, all of this happens on a single call of any of the data retrieval or persistence methods (Save(), FindAll() etc.): ActiveRecordBase gets an ISession from the SessionFactoryHolder. ActiveRecordMediator simpy calls a static method on ActiveRecordBase, so there are no differences with respect to session handling. ActiveRecordBase performs the desired database operation. If there is no exception, ReleaseSession is called by ActiveRecordBase. In case of an exception, FailSession is called instead and the exception is rethrown. SessionFactoryHolder closes the ISession instance. Upon the next call, a new session is created. But what if we need to have a single session span multiple commands? This will be handled in the following articles when we talk about scopes. [Less]

I've been doing some experiments with F# which involves using Windsor (my default choice for a IoC container) and found that Windsor's fluent interface is... not so fluent when used in F#. UPDATE 10/21/2010: The F# team has loosened the syntax a lot ... [More] , F# 2.0 can now consume the Windsor fluent API without any changes. Fluent interface as-is in F# Example: given this code in C#container.Register(Component.For<IMyServiceContract>().ImplementedBy<MyServiceImpl>()); Let's try to translate this to F#. (I'll do it step by step so it's more didactic) Code: container.Register(Component.For<IMyServiceContract>().ImplementedBy<MyServiceImpl>())Compiler says: Error: Successive arguments should be separated by spaces or tupled, and arguments involving function or method applications should be parenthesized.Explanation: Component.For<IMyServiceContract>() is a method application, so it has to be parenthesized: Code: container.Register((Component.For<IMyServiceContract>()).ImplementedBy<MyServiceImpl>())Compiler says: Error: Type constraint mismatch. The type ComponentRegistration<IMyServiceContract> is not compatible with type IRegistration array. The type 'ComponentRegistration<IMyServiceContract>' is not compatible with the type 'IRegistration array'. Explanation: The reason for these errors is that F# expects an array as the parameter for Register, since it's signature is IWindsorContainer Register(params IRegistration[] registrations) and F# doesn't support params arrays, so we have to explicitly construct an array: Code: container.Register([|(Component.For<IMyServiceContract>()).ImplementedBy<MyServiceImpl>()|])Compiler says: Error: This expression has type ComponentRegistration<IMyServiceContract> but is here used with type IRegistration.Explanation: What? But ComponentRegistration<IMyServiceContract> implements the IRegistration interface! Yeah, but Register() takes an array of IRegistration, not an array of ComponentRegistration<IMyServiceContract>, and F# doesn't implement array covariance. You can write this in C#:IMyServiceContract[] arr = new MyServiceImpl[] { new MyServiceImpl() }; but you can't write this in F#:let arr: IMyServiceContract[] = [| MyServiceImpl() |] This is actually a Good Thing since this kind of covariance has some nasty consequences. So we have no option but to cast: Code: container.Register [| (((Component.For<IMyServiceContract>()).ImplementedBy<MyServiceImpl>()) :> IRegistration) |]Compiler says: Warning: This expression should have type 'unit', but has type 'IWindsorContainer'.Explanation: We have to do something about the return value. We're not using it in this example, so we'll just discard it: Code: let _ = container.Register [| (((Component.For<IMyServiceContract>()).ImplementedBy<MyServiceImpl>()) :> IRegistration) |] This finally compiles, but it's way too noisy. Not fluent at all! We could have also written:let _ = container.Register(Seq.to_array (Seq.cast [(Component.For<IMyServiceContract>()).ImplementedBy<MyServiceImpl>()])) but it's just as ugly. Extension method solution We could hide the casting and array stuff in an extension method:module WindsorContainerExtensions = type IWindsorContainer with member x.RegisterComponents (r: seq<#IRegistration>) = let _ = x.Register (Seq.to_array (Seq.cast r)) () which allows us to write:container.RegisterComponents [(Component.For<IMyServiceContract>()).ImplementedBy<MyServiceImpl>()] Much better, but it doesn't quite fit the F# spirit. Function pipelines solution A better-yet solution is to use function pipelining to build a DSL, like FsUnit and FsTest do, so we can write:typeof<IMyServiceContract> |> implementedBy (typeof<MyServiceImpl>) |> registerIn container Here are the functions that support this:let implementedBy impl (service: Type) = (Component.For service).ImplementedBy impl let registerIn (container: IWindsorContainer) registration = container.RegisterComponents [ registration ] It's easy to follow this pattern and implement similar functions to cover more functionality. For example, this sets the lifestyle for a registration:let withLifestyle lifestyle (registration: ComponentRegistration<_>) = (registration.LifeStyle).Is lifestyle Usage:typeof<IMyServiceContract> |> implementedBy (typeof<MyServiceImpl>) |> withLifestyle LifestyleType.Transient |> registerIn container Conclusion Fluent interfaces are cool but quite language-dependent, so if you're designing an API targeting the CLR and thinking of building a fluent interface, make sure you also provide an alternative, simpler, non-fluent API so other languages can build their own flavor of fluent interface (Windsor does provide this, of course) [Less]

Continuing my love fest with the Windsor WCF facility, today I'm going to show you how to add behaviours to your WCF service. Behaviours are the core extension point for WCF and allow you to do pretty much anything with your service. Here's a nice ... [More] brief description by Mehran Nikoo (it was the first thing that popped up on google :) The WCF Facility automatically discovers any registered WCF behaviours and adds them to the service. The really nice thing about this is that because the behaviours are also IoC hosted components, the container can automatically provide their dependencies just like any other component. If you need to use any of your services inside the behaviour, simply inject it through the constructor as normal. Let's look at an example where we want to log the entry and exit from an operation. Here's a simple service: [ServiceContract] public interface IHelloService { [OperationContract] string Hello(string name); } public class HelloService : IHelloService { private readonly ILogger logger; public HelloService(ILogger logger) { this.logger = logger; } public string Hello(string name) { logger.WriteLine("In Hello()"); return string.Format("Hello {0}", name); } } It has a single operation 'Hello' that takes a name and returns 'Hello <name>'. It also has a dependency on ILogger which it uses to log that the Hello operation has been invoked. Now lets create a WCF behaviour: public class TestEndpointBehaviour : IEndpointBehavior { private readonly TestCallContextInitializer callContextInitializer; public TestEndpointBehaviour(TestCallContextInitializer callContextInitializer) { this.callContextInitializer = callContextInitializer; } public void Validate(ServiceEndpoint endpoint){} public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters){} public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime){} public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { foreach (var operation in endpointDispatcher.DispatchRuntime.Operations) { operation.CallContextInitializers.Add(callContextInitializer); } } } We want to write to the logger before and after every operation invocation, to do that we're creating an Endpoint behaviour. The Endpoint behaviour gives you an opportunity, the ApplyDispatchBehaviour method, to add a 'CallContextInitializer' that can intercept operation invocations.  Note that we resolve our CallContextInitializer from the IoC container by expecting it to be injected via a constructor parameter. As an aside, I can't help feeling that the WCF behaviour API is overly complex, it hardly invites you in :) There's no way I would have worked out how to do this without looking at the documentation. Not at all the pit of success. Rant over, here's our CallContextInitializer:   public class TestCallContextInitializer : ICallContextInitializer { private readonly ILogger logger; public TestCallContextInitializer(ILogger logger) { this.logger = logger; } public object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message) { logger.WriteLine("Before Invoke"); return null; } public void AfterInvoke(object correlationState) { logger.WriteLine("After Invoke"); } } The ICallContextInitializer interface has two methods: BeforeInvoke and AfterInvoke where which allow us to execute any actions before and after the operation is invoked. Here we're just using the logger to write some interesting stuff out. Note that because the TestCallContextInitializer is also an IoC component we can resolve any of our services as constructor arguments again. Here we using the same ILogger service that our HelloService uses. Here's the configuration and a little test to show it all working: [TestFixture] public class WCFIntegration_Spikes { private const string tcpEndpointAddress = "net.tcp://localhost:4321/HelloService"; [SetUp] public void SetUp() { } [Test, Explicit] public void Simple_TCP_Service() { var container = new WindsorContainer() .AddFacility<WcfFacility>() .Register( Component.For<ILogger>().ImplementedBy<Logger>(), Component.For<TestCallContextInitializer>(), Component.For<TestEndpointBehaviour>(), Component.For<IHelloService>().ImplementedBy<HelloService>() .ActAs(new DefaultServiceModel().AddEndpoints( WcfEndpoint.BoundTo(new NetTcpBinding { PortSharingEnabled = false }).At(tcpEndpointAddress) )) ); var client = ChannelFactory<IHelloService>.CreateChannel( new NetTcpBinding { PortSharingEnabled = false }, new EndpointAddress(tcpEndpointAddress)); Console.WriteLine(client.Hello("Mike")); container.Dispose(); } } We first register the WcfFacility as usual. Then we register our components. Note that we don't need to do any special configuration for our EndpointBehaviour, the WCF Facility takes care of this for us. When we run the test we get this output to the console: Before Invoke In Hello() After Invoke Hello Mike As expected our behaviour was installed and invoked. Integrating WCF and Windsor like this provides a very slick way of doing web services. I'm very impressed with Craig Neuwirt's work, what a star. Shame he doesn't blog more about it. [Less]

I like getting all my service from the container and I like using AutoMapper. So I added the AutoMapper to the container, a WindsorContainer in this case. The main interface is IMappingEngine, which is implemented by MappingEngine which also ... [More] implements IMappingEngineRunner. This contains a getter to an IConfiguration interface which is also an IConfigurationExpression. So to replace Mapper you need an instance of IMappingEngine and then you can configure the engine as follows: public CustomMapper(IMappingEngine engine) {     _engine = engine;       var runner = _engine as IMappingEngineRunner;     if (runner == null)         return;       var configuration = runner.Configuration as IConfigurationExpression;     if (configuration == null)         return;       configuration.CreateMap<IApplication, B.Application>(); } Next setting up the container, the MappingEngine needs an IConfiguration, the Configuration needs some IObjectMapper instances. private static void RegisterMappingEngine() {     _container.Register(AllTypes.Of<IObjectMapper>()                             .FromAssembly(typeof (IObjectMapper).Assembly)                             .Configure(configurer => configurer.Named(configurer.ServiceType.Name))                             .Configure(configurer => configurer.LifeStyle.Transient));       _container.Register(Component.For<IConfiguration>().ImplementedBy<Configuration>()                             .LifeStyle.Transient.ServiceOverrides(                             ServiceOverride.ForKey("mappers").Eq(                                 "CustomTypeMapMapper",                                 "TypeMapMapper",                                 "NewOrDefaultMapper",                                 "StringMapper",                                 "EnumMapper",                                 "ArrayMapper",                                 "EnumerableMapper",                                 "NullableMapper",                                 "AssignableMapper")                             ));       _container.Register(Component.For<IMappingEngine>().ImplementedBy<MappingEngine>()                             .LifeStyle.Transient); } These are all set as Transient because each CustomMapper can be Singleton and I don’t want the mappings to over lap between the CustomMappers. [Less]

The Castle Windsor fluent registration API is a powerful and beautiful thing, but it's very new and the documentation is still evolving. Mostly I find the best thing is just to read the code, especially the unit tests. Today I wanted to register an ... [More] array of components that all implement the same interface, and then resolve them in a particular order for another component that expects an array of that interface in its constructor. Here's how it's done. First lets define an interface and some types that implement it: public interface IMyInterface { } public class MyFirstThing : IMyInterface {} public class MySecondThing : IMyInterface {} public class MyThirdThing : IMyInterface {} Then we have a component that has a dependency on IMyInterface: public class HasArrayDependency { private readonly IMyInterface[] myInterfaces; public HasArrayDependency(IMyInterface[] myInterfaces) { this.myInterfaces = myInterfaces; } public IMyInterface[] MyInterfaces { get { return myInterfaces; } } } Here's a test showing the registration: [Test] public void Demonstrate_fluent_registration_of_arrays() { var container = new WindsorContainer() .Register( Component.For<HasArrayDependency>() .ServiceOverrides( ServiceOverride.ForKey("myInterfaces").Eq( "MyFirstThing", "MySecondThing", "MyThirdThing" ) ), AllTypes .FromAssembly(Assembly.GetExecutingAssembly()) .BasedOn<IMyInterface>() .WithService.FromInterface(typeof(IMyInterface)) .Configure(c => c.Named(c.Implementation.Name)) ); var hasArrayDependency = container.Resolve<HasArrayDependency>(); Assert.That(hasArrayDependency.MyInterfaces[0].GetType().Name, Is.EqualTo("MyFirstThing")); Assert.That(hasArrayDependency.MyInterfaces[1].GetType().Name, Is.EqualTo("MySecondThing")); Assert.That(hasArrayDependency.MyInterfaces[2].GetType().Name, Is.EqualTo("MyThirdThing")); } There are a couple of things we need to do. If we simply register components like this: var container = new WindsorContainer() .Register( AllTypes .FromAssembly(Assembly.GetExecutingAssembly()) ); By default they will be named with their full type name rather than just the class name, so we have to use the Configure method with the lambda expression to change the component name to the class name. Next we use the ServiceOverrides method to override the default dependency resolution. Here we are saying that for the constructor parameter named 'myInterfaces' we are going to supply the components named 'MyFirstThing', 'MySecondThing', and 'MyThirdThing'. Castle Windsor doesn't provide array parameters with any service of the array type by default, if you want that behaviour you need to use a custom sub dependency resolver as described here. [Less]