This chapter contains an exhaustive listing for pretty much every possible XML configuration scenario for Spring.NET's XML based configuration. If you need to configure an object in a Spring.NET IoC container, and you are using Spring.NET's XML configuration option to do so (which, short of programmatic configuration, is pretty much all you can use for configuration right now), then this chapter will most probably have an example XML fragment that can illustrate what you need to do. Please note that this chapter is not a knee-jerk or belated response to addressing any perceived complexity in the Spring.NET XML configuration. Spring.NET's XML configuration syntax is, in the opinion of the developers (for what that's worth), eminently readable... one has <objects/>, these objects have zero or more <constructor-arg/> or <property/> elements that are generally <ref/>erences to other <object/>s. To use an analogy, Spring.NET's XML configuration reads like a William Weaver translation of an Umberto Eco novel... the words (the XML elements) are easy, but the devil (and salvation) is in the detail. This section details the configuration of one's object definitions. It contains fragments of XML that illustrate the absolute basics, such as how to create a simple object with no dependencies, all the way through to often overlooked features such as instantiating an object from of a method call to another object. This section details how to define an object in Spring.NET XML. If you need somewhere to start, this is the place. The section starts off with the absolute basics of defining an object (the <object/> element), and then describes the setting of constructor arguments and properties. Once you are down with those three cornerstones of configuration (yes, that is really it), the rest of the text in this reference is spent describing the values that one can supply to those constructor arguments and property values. Find below an example of defining an object that has no dependencies. <object name="service" type="Example.Foo, FooAssembly"/> This is the name of the object ( ). This is the assembly qualified name of the object's Type or class ( ). Please note that the scope of the object is implicitly singleton (see of this chapter and in the reference documentation). Defining this object in one's context and then retrieving said object from said context will result in the creation of an instance of the Foo class. The default constructor of the Foo class will be invoked, and since no properties and other other configuration elementts are present, the resulting object will be returned as is. The simple case really is as simple as that. Further (un-annotated) examples of defining an object that has no dependencies can be found below... <object id="anException" type="System.ArgumentException, Mscorlib"/> <object id="anEmptyList" type="System.Collections.ArrayList, Mscorlib"/> <object id="anSqlCommand" type="System.Data.SqlClient.SqlCommand, System.Data"/> This section details the various configuration options available for injecting, handoing, and otherwise defining the classic primitive types. The string and date types are not primitives, but they are described here nevertheless. Spring.NET uses the TypeConverter mechanism that is part of the SDK to handle the conversion from string values in one's XML configuration to the appropriate type. This reference does not go into detail about this mechanism, so you may wish to consult the attendant section of the reference material proper if you are having type conversion issues... This section describes configuring the various numeric types supported by the CLR. Any numeric type can be injected into an object, or made available as an object definition in its own right. Find below the class definition that is used to illustrate configuring numeric values in the following examples. [C#] namespace Example { public class Gauge { private int setting; private float sensitivity; public int Setting { set { this.setting = value; } } public float Sensitivity { set { this.sensitivity = value; } } } } <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="setting" value="213"/> </object> We can also use any of the normal supported conventions (such as hexadecimal) to set values, as shown below. <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="setting" value="0x10"/> </object> <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="sensitivity" value="31000.00"/> </object> Given the above examples, it is trivial to extrapolate the configuration of longs and the various unsigned variants of the numeric types, so no examples of such configuration will be given. Find below the class definition that is used to illustrate configuring date values in the following examples. [C#] namespace Example { public class Gauge { private DateTime lastChecked; public DateTime LastChecked { set { this.lastChecked = value; } } } } <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="lastChecked" value=""/> </object> <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="lastChecked" value=""/> </object> <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="lastChecked" value=""/> </object> Configuring boolean values in one's configuration file (s) is pretty much the same as configuring numeric and date values... one simply uses the value attribute or <value/> element (as appropriate). The only caveat (if indeed it can be considered to be a caveat) is that the value must be one of the following two values... true false Find below the class definition that is used to illustrate configuring boolean values in the following examples. [C#] namespace Example { public class Gauge { private bool isSwitchedOn; public bool IsSwitchedOn { set { this.isSwitchedOn = value; } } } } <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="IsSwitchedOn" value="true"/> </object> <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="IsSwitchedOn" value="false"/> </object> Please note that as with pretty much everything in Spring.NET, the true and false string values are not case sensitive. The string values TRUE, FALSE, True, etc. are all valid. If you wanted to use different values for the true and false string values (perhaps on and off values in the case of the preceding Gauge example), you would need to register a custom TypeConverter implementation (see ). Unsurprisingly, String values are the easiest to configure. Consider the following example of strings that are defined as top level objects... <object id="supportTeamEmail" type="string"> <constructor-arg index="0" value="support@my.company.com"/> </object> <object id="projectManagerEmail" type="string"> <constructor-arg index="0" value="projectManager@my.company.com"/> </object> The index="0" attribute value pair of the constructor-arg element is required so that the correct constructor of the String class can be invoked... don't forget to put it in. (If you do forget to put it in, then a not-very-helpful UnsatisfiedDependencyException will be thrown by the Spring.NET container). Find below the class definition and XML snippets that illustrate the configuration of enumerations. [C#] namespace Example { public enum RunningMode { Off, Starting, Started, SwitchingOff, Off } public class Gauge { private RunningMode runMode; public RunningMode RunMode { set { this.runMode = value; } } } } <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="RunMode" value="Starting"/> </object> <object id="aGauge" type="Example.Gauge, FooAssembly"> <property name="RunMode" value="SwitchingOff"/> </object> Please note that as with pretty much everything in Spring.NET, the string passed to the value of the value attribute is not case sensitive. In the case of this specific example, the string values starting and SWITCHINGOFF are both valid (though not recommended; it's always best to stick to the casing of the original enum, to aid in refactorings). See also . Perhaps unsurprisingly, implementations of the classic Factory pattern can be found all over the Spring.NET codebase... indeed, the core IApplicationContext class is a compelling example of a factory implementation (albeit a very sophisticated example). Spring.NET's support for the factory pattern extends into two distinct areas... supporting factories that are external to the framework, and factories that are internal to the framework. External factory classes would include any factory classes that you may have written: examples of this would include (perhaps) IWiGFactory (to create IWiG implementations), etc. You can integrate any such existing factory classes directly into the Spring.NET container using the factory method support provided by the Spring IoC container. Examples of such integration are are provided below, but do see and for the full lowdown. Spring.NET also has the notion of a special Factory Object (and this notion is encapsulated by the IFactoryObject interface). The IFactoryObject interface is (unsurprisingly) a factory for creating one or more objects. Please do read for a comprehensive explanation of the IFactoryObject interface and the Spring.NET container's special treatment of objects that implement said interface. This section of the documentation will show some example configuration for all (well, most) of the IFactoryObject implementations that come provided out of the box with every Spring.NET release. This section of the documentation presents examples for most of the IFactoryObject implementations that come out of the box with every Spring.NET release. A notable exception to this catalogue of IFactoryObject configuration examples is the AOP-specific ProxyFactoryObject... see for more details regarding that particular IFactoryObject implementation. Most (if not all) of the IFactoryObject implementations referenced in the following configuration examples can be found in the Spring.Objects.Factory.Config namespace; do also consult the attendant API documentation (because most of the IFactoryObject implementations carry configuration examples specific to the objects that they create). One can use the DelegateFactoryObject to (unsurprisingly) create and configure Delegate objects. One trenchant use case for this IFactoryObject (and indeed the very reason that prompted it's creation) is to create declaratively a ConfigListener delegate for use with the IBatis.NET project's SqlMapper class. This approach (of using the DelegateFactoryObject) allows one to keep all of one's SqlMapper configuration together, nice and tidy, in the one place. So lets say we have a service object that we need to inject with a delegate; class definitions for the class that has the dependency on the delegate, the delegate class itself, and a class that supplies the method that will be passed to the delegate when it is created can be found below. [C#] namespace Example { public delegate void GaugeCallback (object sender, GuageEventArgs e); public class Gauge { private GaugeCallback callback; public GaugeCallback Callback { set { this.callback = value; } } public void SomeOperation() { // some logic... callback(this, new GaugeEventArgs()); } } public class MyGaugeListener() { public void HandleGaugeOperation(object sender, GuageEventArgs e) { // do something... } } } The attendant configuration to supply an instance of the Gauge class with a configured GuageCallback delegate would look like so... <objects xmlns="http://www.springframework.net"> <object id="gauge" type="Example.Gauge, FooAssembly"> <property name="callback"> <object type="Spring.Objects.Factory.Config.DelegateFactoryObject"> <property name="delegateType" value="Example.GaugeCallback, FooAssembly"/> <property name="targetObject"> <object type="Example.MyGaugeCallback, FooAssembly"/> </property> </object> </property> </object> </objects> This section details the configuration of one or more contexts... i.e. not the objects themselves, but rather of the hierarchy of contexts in which one's object definitions are contained.