Extension points

Subsystems (ISubSystem)

SubSystems are used by the container internally to handle something external to it. These are the innermost and high impact extension points. Out of the box container uses the following subsystems:

Configuration - configuration subsystems is where configuration of all components and facilities is stored. (implements IConfigurationStore)
Conversion - conversion subsystem is responsible for converting parameters declared as strings (for example in XML config file) to their actual types. It is itself extensible, so it can be taught how to handle additional types, although out of the box it can handle pretty much most types you'll need. (implements IConversionManager and ITypeConverterContext)
Documentation and samples:
- http://castleproject.org/container/documentation/trunk/usersguide/typeconverters.html
- http://mikehadlow.blogspot.com/2010/02/10-advanced-windsor-tricks-10.html
Naming - naming subsystem is where components matching component names / types to actual component handlers happens. (implements INamingSubSystem) Out of the box there are three:
- Default naming subsystem uses direct mapping - if you register certain handler with given name, if you query by that name you will get the same handler. This subsystem uses also IHandlerSelectors which can override that behavior dynamically.
- Key search naming subsystem extends default naming subsystem, by letting you register a delegate (Predicate<string>) to select which component should be used.
  It is recommended to use default subsystem and use IHandlerSelectors to do the filtering instead.
- Naming parts subsystem is an interesting idea, showing how flexible naming subsystems can be. Let the code speak for itself:
```
container.AddComponent("common:key1=true,transportProtocol=MSMQ", typeof(ICommon), typeof(CommonImpl1));
container.AddComponent("common:secure=true,transportProtocol=HTTPS,key1=false", typeof(ICommon), typeof(CommonImpl2));
```
  We register component using not just name, but also a micro DSL, containing set of attribute/value pairs. We can just query the container based on these attribute:
```
var any = container.Resolve<ICommon>("common");
var trueKey1 = container.Resolve<ICommon>("common:key1=true");
var secure = container.Resolve<ICommon>("common:secure=true");
var httpsSecure = container.Resolve<ICommon>("common:transportProtocol=HTTPS,secure=true");
```
  In the first two cases we'll get a CommonImpl1, in last two cases we'll get CommonImpl2.
  This is a nice feature to show the flexibility of NamingSubsystem, but not one you'd use on most projects.
Resources - resource subsystem abstracts how resources are provided to various parts of Windsor/MicroKernel ecosystem. (implements IResourceSubSystem)

While very powerful subsystems are tightly tied to the container and you will want to create your own only to change how the default ones work (if their standard extension points won't suffice) or when you create your own container type extending how default one work, which is pretty much never. Most of the time what you'll need - is to create a facility.

Facilities (IFacility)

Facilities are main way of extending the container. Contrary to subsystems, container itself is agnostic to facilities. A facility is a unit of extension that can be registered into the Castle MicroKernel. It may augment the container functionality in different ways: it can introduce new semantics or integrate the MicroKernel with some external tool or framework. We currently have a set of facilities that you can use and especially see their implementation to learn more.

In container assemblies Castle.MicroKernel.dll you can find the following facilities. Notice that the are many more provided in their own assemblies, but still being part of the Castle project. Many external projects provide their own facilities to integrate with Windsor.

Typed Factory Facility - Provides automatic implementation for factory classes, that you can use in your code to create objects on demand without introducing dependency on the container.
Factory Support Facility - Provides ability for the components to be created by factory objects. You can use it to register things like HttpContext in the container.
Event Wiring Facility - Provides ability to wire up classes exposing events to classes consuming them.
Startable Facility - Provides ability to 'start' and 'stop' objects. Very useful for things like WCF Services that you may want started as soon as your application starts.
Remoting Facility - Provides ability to expose or consume components from another app domain using .NET Remoting.

Component model creation contributors (IContributeComponentModelConstruction)

[Component model creation contributors] inspect and build up component model. This is the right extension point when you want to do things like validation of certain attributes and setting defaults, set some properties of the component model or do any other kind of work with the model before it gets passed down the pipeline.

Model interceptors selectors (IModelInterceptorsSelector)

Model interceptor selectors are called when a proxy is created for a component, and can decide which interceptors should be used for that component. That may include not only interceptors contained in the Interceptors property of the component model, but also additional interceptors.
To use the selector you have to add it to proxy factory's collection of selectors

container.Kernel.ProxyFactory.AddInterceptorSelector(selector);

See this blogpost for an example of usage.

Handler selectors (IHandlerSelectors)

As mentioned above default naming subsystem uses handler selectors to override its decision as to choose which component should be used to satisfy certain request. Mostly likely usage is in scenarios where you need to make that decision dynamically. See this blogpost for an example of usage.

To use the selector you have to add it to kernel's collection of selectors

container.Kernel.AddHandlerSelector(selector);

ISubDependencyResolver

Sample custom resolvers:

ILazyComponentLoader

http://devlicio.us/blogs/krzysztof_kozmic/archive/2009/11/16/castle-windsor-lazy-loading.aspx

IReleasePolicy

http://castleproject.org/container/documentation/trunk/advanced/releasepolicy.html

ILifecycleConcern

http://castleproject.org/container/documentation/trunk/usersguide/lifecycles.html

IProxyHook

Lifestyles (ILifestyleManager)

Sample custom lifestyle: http://bugsquash.blogspot.com/2009/11/windsor-managed-httpmodules.html

Component activators (IComponentActivator)

Sample custom activator: http://www.tunatoksoz.com/post/Castle-Custom-Component-Activators.aspx

IWindsorInstaller

Packages the registration of related components. It can considered as a lighter, looser facility.

Samples:

Page Operations

Browse Space