When a component is requested from Windsor container, the container goes through several steps in order to provide the instance. The image on the right depicts the more important aspects of these steps. We'll discuss them here in more detail.
ℹ️ On instance lifecycle and lifestyle: This page serves two-fold purpose. First it explains what Windsor does when an instance of a component is requested regardless of the component's lifestyle. In addition to that, it describes the first part of the component's lifecycle, that is its inception and birth (or in technical terms, what leads to instance being created, and how it's being created). Please do keep in mind that is not the entire lifecycle of an instance, it's just the first step. To learn about the whole lifecycle, all the way to component's death see the page about instance lifecycle
The first step performed by the container when a component is requested is to check whether the requested component was registered with the container. The container asks its naming subsystem for the component, and if the component could not be found, the container will try to register it lazily, and if that does not succeed, a ComponentNotFoundException will be thrown.
Assuming the correct component can be found, the container will poll its handler and ask it to resolve the component instance.
Handler does a few things:
- It invokes all
ComponentResolvingDelegates associated with it, giving them a chance to affect resolution before it actually starts. That's for example when delegates passed to DynamicParameters method of fluent registration API are invoked. - When no in-line arguments were provided, it checks whether the component and all its mandatory dependencies can be resolved. If not, a
HandlerExceptionis thrown. - Otherwise, handler asks its lifestyle manager to resolve the component.
Lifestyle manager has a relatively simple role. If it has a component instance it can reuse, it gets it and returns the instance immediately back to the handler. If not, it asks its component activator to create one for it.
ℹ️ Component activators: Component activator is responsible for creating the instance of the component. Various activators have various ways of achieving that. When you create your component via UsingFactoryMethod the delegate you provided will be invoked to create the instance. Factory Support Facility or Remoting Facility have their own set of activators that perform custom initialization of the components.
Most of the time you will be using DefaultComponentActivator which does the following:
- Instantiates the component by invoking its constructor. ℹ️ How constructor is selected: To learn how default component activator selects constructor to use see here.
- When the instance is created, it then resolves component's property dependencies. ℹ️ How properties are injected: To learn how default component activator injects dependencies into properties see here.
- When the component is fully created it invokes all commission concerns of the component.
- Triggers
ComponentCreatedevent on the kernel. - Returns the instance back to lifestyle manager.
Lifestyle manager may save the instance to some contextual cache if needed, so that it can be later reused, and passes it down to the handler. Handler optionally asks release policy to track the component, if it's allowed and required, and then passes it down to the container, which returns it to the user.