diff --git a/doc/reference/src/index.xml b/doc/reference/src/index.xml index 2ffd0ce3..ef8fe9de 100644 --- a/doc/reference/src/index.xml +++ b/doc/reference/src/index.xml @@ -1,645 +1,641 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -]> - - - The Spring.NET Framework - - Reference Documentation - - Version 2.0.0 - - Last Updated January 11, 2013 (Latest - documentation) - - - - Mark - - Pollack - - - - Rick - - Evans - - - - Aleksandar - - Seovic - - - - Bruno - - Baia - - - - Erich - - Eichinger - - - - Federico - - Spinazzi - - - - Rob - - Harrop - - - - Griffin - - Caprio - - - - Ruben - - Bartelink - - - - Choy - - Rim - - - - Erez - - Mazor - - - - Stephen - - Bohlen - - - - The Spring - - Java Team - - - - - Copies of this document may be made for your own use and for - distribution to others, provided that you do not charge any fee for such - copies and further provided that each copy contains this Copyright - Notice, whether distributed in print or electronically. - - - - - - &preface; - - &overview; - - &background; - - &migration; - - - Core Technologies - - - This initial part of the reference documentation covers all of - those technologies that are absolutely integral to the Spring - Framework. - - Foremost amongst these is the Spring Framework's Inversion of - Control (IoC) container. A thorough treatment of the Spring Framework's - IoC container is closely followed by comprehensive coverage of Spring's - Aspect-Oriented Programming (AOP) technologies. The Spring Framework has - its own AOP framework, which is conceptually easy to understand, and - which successfully addresses the 80% sweet spot of AOP requirements in - enterprise programming. - - The core functionality also includes an expression language for - lightweight scripting and a ui-agnostic validation framework. - - Finally, the adoption of the test-driven-development (TDD) - approach to software development is certainly advocated by the Spring - team, and so coverage of Spring's support for integration testing is - covered (alongside best practices for unit testing). The Spring team - have found that the correct use of IoC certainly does make both unit and - integration testing easier (in that the presence of properties and - appropriate constructors on classes makes them easier to wire together - on a test without having to set up service locator registries and - suchlike)... the chapter dedicated solely to testing will hopefully - convince you of this as well. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - &objects; - - &objects-misc; - - &resources; - - &threading; - - &pool; - - &misc; - - &expressions; - - &validation; - - - - &aop; - - &aop-aspect-library; - - &logging; - - &testing; - - - - Middle Tier Data Access - - - This part of the reference documentation is concerned with othe - middle tier, and specifically the data access responsibilities of said - tier. - - Spring's comprehensive transaction management support is covered - in some detail, followed by thorough coverage of the various middle tier - data access frameworks and technologies that the Spring Framework - integrates with. - - - - - - - - - - - - - - - - - - - - - - - - - &transaction; - - &dao; - - &dbprovider; - - &ado; - - &orm; - - - - The Web - - - This part of the reference documentation covers the Spring - Framework's support for the presentation tier, specifically web-based - presentation tiers. - - - - - - - - - - - - - - - - - - - - - &web; - - &ajax; - - &web-mvc; - - &web-mvc3; - - - - Services - - - This part of the reference documentation covers the Spring - Framework's integration with .NET distributed technologies such as .NET - Remoting, Enterprise Services, Web Services. Integration with WCF - Services is forthcoming. Please refer to the introduction chapter for - more details. - - - - - - - - - - - - - - - - - - - - - - - - - &psa-intro; - - &remoting; - - &services; - - &webservices; - - &wcf; - - - - Integration - - - This part of the reference documentation covers the Spring - Framework's integration with a number of related enterprise .NET - technologies. - - - - - - - - - - - - - - - - - - - - - - - - - &messaging; - - &messaging-ems; - - &msmq; - - &scheduling; - - &templating; - - - - Code-Based Configuration + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]> + + + The Spring.NET Framework + + Reference Documentation + + Version 2.0.0 + + Last Updated January 11, 2013 (Latest + documentation) + + + + Mark + + Pollack + + + + Rick + + Evans + + + + Aleksandar + + Seovic + + + + Bruno + + Baia + + + + Erich + + Eichinger + + + + Federico + + Spinazzi + + + + Rob + + Harrop + + + + Griffin + + Caprio + + + + Ruben + + Bartelink + + + + Choy + + Rim + + + + Erez + + Mazor + + + + Stephen + + Bohlen + + + + The Spring + + Java Team + + + + + Copies of this document may be made for your own use and for + distribution to others, provided that you do not charge any fee for such + copies and further provided that each copy contains this Copyright + Notice, whether distributed in print or electronically. + + + + + + &preface; + + &overview; + + &background; + + &migration; + + + Core Technologies + - In this reference document, we’ll explore the newest addition to - the configuration story for the Spring.NET Dependency Injection - container: code-based configuration, or simply CodeConfig, intended to - begin to address many of the shortcomings of the XML-based configuration - approach. - - At the core of Spring.NET is a powerful and flexible dependency - injection container, offering object assembly and construction services - atop which the remainder of the Spring.NET Framework is based. - Historically, the primary manner of configuring this dependency - injection container has been XML configuration files. Object - definitions, essentially recipes to be used by the container when - constructing objects of various types, are expressed in XML and then - parsed and interpreted by the container as it is initialized at - run-time. - - While there are several positive aspects to expressing - configuration metadata in XML files, there are also many problems with - this approach including the verbosity of XML and its heavy dependence on - string-literals which are both prone to typing errors and unusually - resistant to most modern refactoring tools in use today. The CodeConfig - approach removes these problems by providing a type safe, code-based, - approach to dependency injection. It keeps the configuration metadatda - external to your class so your class can be a POCO, free of any DI - related annotations. + This initial part of the reference documentation covers all of + those technologies that are absolutely integral to the Spring + Framework. + + Foremost amongst these is the Spring Framework's Inversion of + Control (IoC) container. A thorough treatment of the Spring Framework's + IoC container is closely followed by comprehensive coverage of Spring's + Aspect-Oriented Programming (AOP) technologies. The Spring Framework has + its own AOP framework, which is conceptually easy to understand, and + which successfully addresses the 80% sweet spot of AOP requirements in + enterprise programming. + + The core functionality also includes an expression language for + lightweight scripting and a ui-agnostic validation framework. + + Finally, the adoption of the test-driven-development (TDD) + approach to software development is certainly advocated by the Spring + team, and so coverage of Spring's support for integration testing is + covered (alongside best practices for unit testing). The Spring team + have found that the correct use of IoC certainly does make both unit and + integration testing easier (in that the presence of properties and + appropriate constructors on classes makes them easier to wire together + on a test without having to set up service locator registries and + suchlike)... the chapter dedicated solely to testing will hopefully + convince you of this as well. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + &objects; + + &objects-misc; + + &resources; + + &threading; + + &pool; + + &misc; + + &expressions; + + &validation; + + + + &aop; + + &aop-aspect-library; + + &logging; + + &testing; + + + + Middle Tier Data Access + + + This part of the reference documentation is concerned with othe + middle tier, and specifically the data access responsibilities of said + tier. + + Spring's comprehensive transaction management support is covered + in some detail, followed by thorough coverage of the various middle tier + data access frameworks and technologies that the Spring Framework + integrates with. + + + + + + + + + + + + + + + + + + + + + + + + + &transaction; + + &dao; + + &dbprovider; + + &ado; + + &orm; + + + + The Web + + + This part of the reference documentation covers the Spring + Framework's support for the presentation tier, specifically web-based + presentation tiers. + + + + + + + + + + + + + + + + + + + + + &web; + + &ajax; + + &web-mvc; + + &web-mvc3; + + + + Services + + + This part of the reference documentation covers the Spring + Framework's integration with .NET distributed technologies such as .NET + Remoting, Enterprise Services, Web Services. Integration with WCF + Services is forthcoming. Please refer to the introduction chapter for + more details. + + + + + + + + + + + + + + + + + + + + + + + + + &psa-intro; + + &remoting; + + &services; + + &webservices; + + &wcf; + + + + Integration + + + This part of the reference documentation covers the Spring + Framework's integration with a number of related enterprise .NET + technologies. + + + + + + + + + + + + + + + + + + + + + + + + + &messaging; + + &messaging-ems; + + &msmq; + + &scheduling; + + &templating; + + + + Code-Based Configuration + + In this reference document, we’ll explore the newest addition to + the configuration story for the Spring.NET Dependency Injection + container: code-based configuration, or simply CodeConfig, intended to + begin to address many of the shortcomings of the XML-based configuration + approach. + + At the core of Spring.NET is a powerful and flexible dependency + injection container, offering object assembly and construction services + atop which the remainder of the Spring.NET Framework is based. + Historically, the primary manner of configuring this dependency + injection container has been XML configuration files. Object + definitions, essentially recipes to be used by the container when + constructing objects of various types, are expressed in XML and then + parsed and interpreted by the container as it is initialized at + run-time. + + While there are several positive aspects to expressing + configuration metadata in XML files, there are also many problems with + this approach including the verbosity of XML and its heavy dependence on + string-literals which are both prone to typing errors and unusually + resistant to most modern refactoring tools in use today. The CodeConfig + approach removes these problems by providing a type safe, code-based, + approach to dependency injection. It keeps the configuration metadatda + external to your class so your class can be a POCO, free of any DI + related annotations. - - - - - - - - - + + + + + + + + + - + - &codeconfig-migration-example; - &codeconfig-context; - &codeconfig-attribute-reference; - &codeconfig-sample-apps; - - - - VS.NET Integration - - - This part of the reference documentation covers the Spring - Framework's integration with VS.NET - - - - - - - - - &vsnet; - - - - Quickstart applications - - - This part of the reference documentation covers the quickstart - applications included with Spring that demonstrate features in a code - centric manner. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - &quickstarts; - - &aop-quickstart; - - &remoting-quickstart; - - &web-quickstart; - - &springair; - - &data-quickstart; - - &tx-quickstart; - - &nh-quickstart; - - &quartz-quickstart; - - &nms-quickstart; - - &ems-quickstart; - - &msmq-quickstart; - - &wcf-quickstart; - - - - Spring.NET for Java developers - - - This part of the reference documentation is for Java developers - who would like a quick orientation to what is different between the Java - and .NET versions of the framework. - - - - - - - - - &javadevelopers; - - - - - - Appendices - - &classic-spring; - - &xsd-configuration; - - &xml-custom; - - &xsd; - - + &codeconfig-migration-example; + &codeconfig-context; + &codeconfig-attribute-reference; + &codeconfig-sample-apps; + + + + VS.NET Integration + + + This part of the reference documentation covers the Spring + Framework's integration with VS.NET + + + + + + + + + &vsnet; + + + + Quickstart applications + + + This part of the reference documentation covers the quickstart + applications included with Spring that demonstrate features in a code + centric manner. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + &quickstarts; + + &aop-quickstart; + + &remoting-quickstart; + + &web-quickstart; + + &springair; + + &data-quickstart; + + &tx-quickstart; + + &nh-quickstart; + + &quartz-quickstart; + + &nms-quickstart; + + &ems-quickstart; + + &msmq-quickstart; + + &wcf-quickstart; + + + + Spring.NET for Java developers + + + + This part of the reference documentation is for Java developers + who would like a quick orientation to what is different between the Java + and .NET versions of the framework. + + + + + + + + &javadevelopers; + + + + + Appendices + &classic-spring; + &xsd-configuration; + &xml-custom; + &xsd; + + + diff --git a/doc/reference/src/objects.xml b/doc/reference/src/objects.xml index 7739da55..e180dbd1 100644 --- a/doc/reference/src/objects.xml +++ b/doc/reference/src/objects.xml @@ -29,8 +29,7 @@ This chapter covers the Spring Framework implementation of the Inversion of Control (IoC) - See the section entitled + See the section entitled principle The Spring.Core assembly is the basis for @@ -54,7 +53,7 @@ in this chapter in descriptions of Spring's IoC container. If you are new to Spring.NET or IoC containers in general, you may - want to consider starting with , which + want to consider starting with , which contains a number of introductory level examples that actually demonstrate a lot of what is described in detail below. Don't worry if you don't absorb everything at once... those examples serve only to paint a picture @@ -70,15 +69,15 @@ the Spring IoC container and is responsible for instantiating, configuring, and assembling many of the objects in your application. The container gets its instructions on what objects to instantiate, configure, - and assemble by reading configuration metadata. The configuration metadata - is represented in XML. The configuration metadata allows you to express + and assemble by reading configuration meta data. The configuration meta data + is represented in XML. The configuration meta data allows you to express the objects that compose your application and the rich interdependencies between such objects. - Note that other ways to specify the metadata, such as attributes + Note that other ways to specify the meta data, such as attributes and .NET code, are planned for future releases, the core IoC container - does not assume any specific metadata format. The Java version of Spring + does not assume any specific meta data format. The Java version of Spring already supports such functionality. @@ -94,33 +93,33 @@ Configuration for more details. The following diagram is a high-level view of how Spring works. Your - application classes are combined with configuration metadata so that after + application classes are combined with configuration meta data so that after the ApplicationContext is created and initialized, you have a fully configured and executable system or application. - + - Configuration metadata + Configuration meta data As the preceding diagram shows, the Spring IoC container consumes - a form of configuration metadata; this - configuration metadata represents how you as an application developer + a form of configuration meta data; this + configuration meta data represents how you as an application developer tell the Spring container to instantiate, configure, and assemble the - objects in your application. Configuration metadata is supplied in a + objects in your application. Configuration meta data is supplied in a simple and intuitive XML format - XML-based metadata is by far the most commonly used form of - configuration metadata. It is not however the only form of - configuration metadata that is allowed. The Spring IoC container + XML-based meta data is by far the most commonly used form of + configuration meta data. It is not however the only form of + configuration meta data that is allowed. The Spring IoC container itself is totally decoupled from the format in which this - configuration metadata is actually written. Attribute based and code - based metadata will be part of an upcoming release and it is already + configuration meta data is actually written. Attribute based and code + based meta data will be part of an upcoming release and it is already part of the Spring Java framework. @@ -139,7 +138,7 @@ domain objects. The following example shows the basic structure of XML-based - configuration metadata: + configuration meta data: <objects xmlns="http://www.springframework.net"> @@ -167,12 +166,12 @@ Spring.NET comes with an XSD schema to make the validation of the XML object definitions a whole lot easier. The XSD document is thoroughly documented so feel free to take a peek inside (see ). The XSD is currently used in the + linkend="springobjectsxsd"/>). The XSD is currently used in the implementation code to validate the XML document. The XSD schema serves a dual purpose in that it also facilitates the editing of XML object definitions inside an XSD aware editor (typically Visual Studio) by providing validation (and Intellisense support in the case of Visual - Studio). You may wish to refer to for more + Studio). You may wish to refer to for more information regarding such integration. @@ -182,7 +181,7 @@ Instantiating a Spring IoC container is straightforward. The location path or paths suppied to an IApplicationContext constructor are actually resource strings that allow the container to load configuration - metadata from a variety of external resources such as the local file + meta data from a variety of external resources such as the local file system, embedded assembly resources, and so on. IApplicationContext context = new XmlApplicationContext("services.xml", "data-access.xml"); @@ -229,7 +228,7 @@ linkend="objects-dependencies">Dependencies. - Loading configuration metadata from non-default resource + <title>Loading configuration meta data from non-default resource locations In the previous example the configuration resources are assumed @@ -255,8 +254,8 @@ After you learn about Spring's IoC container, you may want to know more about Spring's IResource - abstraction to load metadata from other locations as desribed below - and alsoin the chapter + abstraction to load meta data from other locations as desribed below + and alsoin the chapter These resources are most frequently files or URLs but can also @@ -270,7 +269,7 @@ referring to a resource that has been embedded inside a .NET assembly, assembly://<AssemblyName>/<NameSpace>/<ResourceName>. The IResource abstraction is explained further in - . + . To create an embedded resource using Visual Studio you must @@ -319,7 +318,7 @@ language="csharp">IApplicationContext ctx = ContextRegistry.GetContext(); The ContextRegistry is used to both instantiate the application context and to perform service locator style access to - other objects. (See for more + other objects. (See for more information). The glue that makes this possible is an implementation of the Base Class Library (BCL) provided IConfigurationSectionHandler interface, namely the @@ -348,12 +347,12 @@ Spring.NET comes with an XSD schema to make the validation of the XML object definitions a whole lot easier. The XSD document is thoroughly documented so feel free to take a peek inside (see ). The XSD is currently used in the + linkend="springobjectsxsd"/>). The XSD is currently used in the implementation code to validate the XML document. The XSD schema serves a dual purpose in that it also facilitates the editing of XML object definitions inside an XSD aware editor (typically Visual Studio) by providing validation (and Intellisense support in the case - of Visual Studio). You may wish to refer to + of Visual Studio). You may wish to refer to for more information regarding such integration. Your XML object definitions can also be defined within the @@ -387,18 +386,18 @@ </configuration> Other options available to structure the configuration files are - described in and - . + described in and + . The IApplicationContext can be configured to register other resource handlers, custom parsers to integrate user-contributed XML schema into the object definitions section, type converters, and define type aliases. These features are discussed in - section + section - Composing XML-based configuration metadata + Composing XML-based configuration meta data It can be useful to have object definitions span multiple XML files. Often each individual XML configuration file represents a @@ -485,12 +484,12 @@ IList userList = service.GetUserNames(); Object definition overview A Spring IoC container manages one or more objects. These objects - are created with the configuration metadata that you supply to the + are created with the configuration meta data that you supply to the container. Within the container itself, these object definitions are represented as IObjectDefinition objects, which - contain (among other information) the following metadata: A type name: typically the actual @@ -518,15 +517,15 @@ IList userList = service.GetUserNames(); - This metadata translates to a set of properties that make up each + This meta data translates to a set of properties that make up each object definition. The following table lists some of these properties, with links to documentation Object definition explanation - + - + @@ -540,57 +539,55 @@ IList userList = service.GetUserNames(); type - + id and name - + singleton or prototype - + object properties - + constructor arguments - + autowiring mode - + dependency checking mode - + initialization method - + destruction method - + @@ -610,7 +607,7 @@ IList userList = service.GetUserNames(); registration through the methods RegisterSingleton(..) and RegisterObjectDefinition(..). However, typical - applications work soley with objects defined through metadata object + applications work soley with objects defined through meta data object definitions. @@ -634,7 +631,7 @@ IList userList = service.GetUserNames(); when applying advice to a set of objects related by name. - When using XML-based configuration metadata, you use the + When using XML-based configuration meta data, you use the 'id' and/or 'name'attributes to specify the object identifier(s). The 'id' attribute allows you to specify exactly one id, and because it is a @@ -676,8 +673,8 @@ IList userList = service.GetUserNames(); not always adequate, however. It is sometimes desirable to introduce an alias for an object that is defined elsewhere. This is commonly the case in large systems where configuration is split amongst each - subsystem, each subsystem having its own set of object defintions. - In XML-based configuration metadata, you can use of the + subsystem, each subsystem having its own set of object definitions. + In XML-based configuration meta data, you can use of the <alias/> element to accomplish this. <alias name="fromName" alias="toName"/> @@ -686,14 +683,14 @@ IList userList = service.GetUserNames(); fromName, may also after the use of this alias definition, be referred to as toName. - For example, the configuration metadata for subsystem A may + For example, the configuration meta data for subsystem A may refer to a DbProvider via the name 'SubsystemA-DbProvider. The - configuration metadata for subsystem B may refer to a DbProvider via + configuration meta data for subsystem B may refer to a DbProvider via the name 'SubsystemB-DbProvider'. When composing the main application that uses both these subsystems the main application refers to the DbProvider via the name 'MyApp-DbProvider'. To have all three names refer to the same object you add to the MyApp - configuration metadata the following aliases definitions: + configuration meta data the following aliases definitions: <alias name="SubsystemA-DbProvider" alias="SubsystemB-DbProvider"/> <alias name="SubsystemA-DbProvider" alias="MyApp-DbProvider"/> @@ -711,10 +708,10 @@ IList userList = service.GetUserNames(); An object definition essentially is a recipe for creating one or more objects. The container looks at the recipe for a named object when - asked, and uses the configuration metadata encapsulated by that object + asked, and uses the configuration meta data encapsulated by that object definition to create (or acquire) an actual object. - If you are using XML-based configuration metadata, you can specify + If you are using XML-based configuration meta data, you can specify the type of object that is to be instantiated in the 'type' attribute of the <object/> element. This @@ -758,13 +755,13 @@ IList userList = service.GetUserNames(); IoC you are going to use for that specific object, you may need to create a default constructor. - With XML-based configuration metadata you can specify your + With XML-based configuration meta data you can specify your object class as follows: <object id="exampleObject" type="Examples.ExampleObject, ExamplesLibrary"/> For details about the mechanism for supplying arguments to the constructor (if required), and setting object instance properties after the object is constructed, see . + linkend="objects-factory-collaborators"/>. This XML fragment describes an object definition that will be identified by the exampleObject name, instances @@ -837,7 +834,7 @@ IList userList = service.GetUserNames(); For details about the mechanism for supplying (optional) arguments to the factory method and setting object instance properties after it has been returned from the factory, see + linkend="object-factory-properties-detailed"/> @@ -943,7 +940,7 @@ IList userList = service.GetUserNames(); type="GenericsPlay.ExampleGenericObject&lt;GenericDictionary&lt;int , string>>, GenericsPlay" /> or even shorter <object id="myOtherOtherGenericObject" type="GenericsPlay.ExampleGenericObject&lt;MyIntStringDictionary>, GenericsPlay" /> - Refer to for + Refer to for additional information on using type aliases. @@ -1049,7 +1046,7 @@ public class TestGenericObjectFactory look up its dependencies, and does not know the location or class of the dependencies. Long sections of initialization code that you used to hide in a #region tag simply go away, and are placed by container - configuration metadata. One can also consider this clean up an + configuration meta data. One can also consider this clean up an application of the principal of Separation of Concerns. Before using DI, you class was responsible for business logic AND its configuration, it was concerns with doing more than one thing. DI removes the @@ -1175,11 +1172,11 @@ namespace SimpleApp Type aliases - + - + - + @@ -1395,7 +1392,7 @@ namespace SimpleApp programatically), but rather with an XML definition file which will be converted internally into instances of these classes, and used to load an entire Spring IoC container instance. Refer to for more information regarding + linkend="objects-objects-conversion"/> for more information regarding type conversion, and how you can design your classes to be convertible by Spring.NET. @@ -1506,7 +1503,7 @@ namespace SimpleApp Examples of dependency injection - First, an example of using XML-based configuration metadata for + First, an example of using XML-based configuration meta data for setter-based DI. A small part of a Spring XML configuration file specifying some object definitions:<object id="exampleObject" type="Examples.ExampleObject, ExamplesLibrary"> @@ -1661,7 +1658,7 @@ public class MixedIocObject As mentioned in the previous section, you can define object properties and constructor arguments as either references to other managed objects (collaborators), or as values defined inline. Spring's - XML-based configuration metadata supports sub-element types within its + XML-based configuration meta data supports sub-element types within its <property/> and <constructor-arg/> elements for this purpose. @@ -1724,7 +1721,7 @@ public class MixedIocObject referenced, named object actually exists. In the second variation, no validation is performed on the value that is passed to the targetName property of the client object. Typos - are only discovered (with ost mikely fatal results) when the + are only discovered (with most likely fatal results) when the 'client' object is actually instantiated. If the 'client' object is a prototype object, this typo and the resulting exception may only be discovered long after the container is deployed. @@ -1752,7 +1749,7 @@ public class MixedIocObject </property> The above configuration will result in the string " \n\r\t". - Note, that you don't have to explicitely specifiy the 'xml' + Note, that you don't have to explicitly specify the 'xml' namespace on top of your configuration. @@ -1766,7 +1763,7 @@ public class MixedIocObject of the specified property to be a reference to another object (a collaborator) managed by the container. The referenced object is a dependency of the object whose property will be set, and it is - initialzed on demand as needed before the property is set. (If the + initialized on demand as needed before the property is set. (If the collaborator is a singleton object it may be initialized already by the container.) All references are ultimately just a reference to another object. Scoping and validation depend on whether you specify @@ -1900,7 +1897,7 @@ public class MixedIocObject it will configure the collection by using the getter property to obtain a reference to the collection class and then proceed to add the additional elements to the existing collection. This results in an - additive behavior for collection properties that are exposed in this + additive behaviour for collection properties that are exposed in this manner. The value of a Dictionary entry, or a set value, can @@ -1910,7 +1907,7 @@ public class MixedIocObject The shortcut forms for value and references are useful to reduce XML verbosity when setting collection properties. See for more information. + linkend="objects-shortcutforms"/> for more information. @@ -1924,10 +1921,10 @@ public class MixedIocObject for IList<T> and the XML attributes key-type and value-type for IDictionary<TKey, TValue>. The values of the - collection are automaticaly converted from a string to the appropriate + collection are automatically converted from a string to the appropriate type. If you are using your own user-defined type as a generic type parameter you will likely need to register a custom type converter. - Refer to for more + Refer to for more information. The implementations of IList<T> and IDictionary<TKey, TValue> that is created are System.Collections.Generic.List and @@ -2089,13 +2086,13 @@ public class MixedIocObject administrator=administrator@example.com // from parent sales=sales@example.com // from child -support=support@example.co.uk // overriden by child +support=support@example.co.uk // overridden by child The child Properties collection's value set inherits all property elements from the parent <name-values/>, and the child's value for the support value overrides the value in the parent collection. This - merging behavior applies similarly to the + merging behaviour applies similarly to the <list/>, <dictionary/>, and <set/> collection types. In the specific case @@ -2115,7 +2112,7 @@ support=support@example.co.uk // overriden by child Null and empty values Spring treats empty arguments for properties and the like as - empty Strings. The following XML-based configuration metadata snippet + empty Strings. The following XML-based configuration meta data snippet sets the email property to the empty String value ("") <object type="Examples.ExampleObject, ExamplesLibrary"> @@ -2146,8 +2143,8 @@ support=support@example.co.uk // overriden by child An indexer lets you set and get values from a collection using a familiar bracket [] notation. Spring's XML configuration supports the setting of indexer properties. Overloaded - indexers as well as multiparameter indexers are also supported. The - property expression parser described in + indexers as well as multi-parameter indexers are also supported. The + property expression parser described in is used to perform the type conversion of the indexer name argument from a string in the XML file to a matching target type. As an example consider the following class public class Person @@ -2467,7 +2464,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList If an object is a dependency of another that usually means that one object is set as a property of another. Typically you accomplish this with the <ref/> element in XML-based - configuration metadata. However, sometimes dependencies between objects + configuration meta data. However, sometimes dependencies between objects are less direct; for example, a static initializer in a class needs to be triggered, such as device driver registration. The depends-on attribute can explicitly force one or more @@ -2560,7 +2557,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList autowired. Using autowiring, it is possible to reduce or eliminate the need to specify properties or constructor arguments, thus saving a significant amount of typing. When using XML-based configuration - metadata, the autowire mode for an object definition is specified by + meta data, the autowire mode for an object definition is specified by using the autowire attribute of the <object/> element. The following values are allowed: @@ -2568,9 +2565,9 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList Autowiring modes - + - + @@ -2705,11 +2702,343 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList arbitrarily resolved. Instead, if no unique object definition is available, an Exception will be thrown. - When deciding whether to use autowiring, there is no wrong or + In the latter scenario, you have several options: + + + + Abandon auto wiring in favour of explicit wiring. + + + + Avoid auto wiring for an object definition by setting its + autowire-candidate attributes to false as described in the next + section. + + + + Designate a single object definition as the primary candidate by + setting the primary attribute of its <object/> element to + true. + + + + Implement the more fine-grained control available with + attribute-based configuration. + + + + When deciding whether to use auto wiring, there is no wrong or right answer in all cases. A degree of consistency across a project is - best though; for example, if autowiring is not used in general, it might - be confusing to developers to use it just to wire one or two object + best though; for example, if auto wiring is not used in general, it might + be confusing for developers to use it just to wire one or two object definitions. + + + Excluding an object from auto wiring + + On a per-object basis, you can exclude an object from auto wiring. In + Spring's XML format, set the autowire-candidate + attribute of the <object/> element to + false; the container makes that specific object + definition unavailable to the auto wiring infrastructure (including + attribute style configurations such as + [Autowired]). + + You can also limit auto wire candidates based on pattern-matching + against object names. The top-level + <objects/> element accepts one or more + patterns within its default-autowire-candidates + attribute. For example, to limit auto wire candidate status to any + object whose name ends with Repository, provide a + value of *Repository. To provide multiple + patterns, define them in a comma-separated list. An explicit value of + true or false for a object + definitions autowire-candidate attribute always + takes precedence, and for such objects, the pattern matching rules do + not apply. + + These techniques are useful for objects that you never want to + be injected into other objects by auto wiring. It does not mean that an + excluded object cannot itself be configured using auto wiring. Rather, + the object itself is not a candidate for auto wiring other + objects. + + + + Using [Autowire] Attribute for fine-grained control + + The [Autowire] attribute in the + Spring.Objects.Factory.Attributes namespace can be + used to mark a variable, property or method for automatically wiring + by injection. It works similar to the auto wire configuration described + in the paragraph above with a byType setting, + except that you can define variables, properties or methods + specifically that you want to autowire. In a latter paragraph you will + see how you can even further define the object or value to + inject. + + To get the [Autowire] attribute working you + need to add the auto wire post processor into your spring configuration + file. + + <object type="Spring.Objects.Factory.Attributes.RequiredAttributeObjectPostProcessor, Spring.Core"/> + + To use the auto wire attribute on a variable, it can be private + or public. The following code shows how to use the attribute. The post + processor will try to find a registered object that is from the + requested type. If more than one registered objects are found from + that type you will get an ObjectCreationException. + To prevent or control this situation you can use the + primary attribute in the + <object> definition, later you will see an + example for this situation. + + public class SomeObject +{ + ... + + [Autowired] + private IFoo hello; + + [Autowired] + public IFoo Hello { get; set; } + + ... +} + + You can also use the auto wire attribute to inject into methods. + In this case all parameters are looked up and found objects of the + requested type injected into the method parameters. You are not + restricted to a single method parameter. + + public class SomeObject +{ + public IFoo hello; + + [Autowired] + private void Prepare(IFoo hello) + { + this.hello = hello; + } +} + + If you have several objects defined from the same type you can + make the following change to the <object> + definition and define one of the objects as + primary. In case the container will find several + objects from a requested type but will check if there is a + primary object and if true will use this object + instead. The container will not throw a + ObjectCreationException. If the container finds + more than one objects for the requested type as + primary, the container will throw a + ObjectCreationException. + + <object id="HelloFoo" type="Spring.Objects.Factory.Attributes.ByType.HelloFoo, Spring.Core.Tests" + primary="true"/> + + You can also use the auto wire attribute for injection in to a + List<T>, ISet<T> or Dictionary<string, T> type. In + this case the container looks up for the requested type defined in the + generic part of the definition and will create a List<T>, + HashedSet<T> or Dictionary<string, T> with all found + objects injected. For the dictionary type the key is the registered + name of the object. + + public class AutowireLists +{ + [Autowired] + public IList<IFoo> foosList; + + [Autowired] + public Spring.Collections.Generic.ISet<IFoo> foosSet; + + [Autowired] + public IDictionary<string, IFoo> foosDictionary; +} + + By default all found autowired objects are treated as required. + This means if the container can't find an registered object of the + requested type it will throw on + ObjectCreationException. For this situation you can + use the Required property of the + [Autowire] attribute to mark an object as not + required and therefore will not throw an + ObjectCreationException. + + public class AutowirePropertyNotRequired +{ + [Autowired(Required = false)] + public IFoo Hello { get; set; } +} + + The [Autowire] attribute is also processed in + the case of an inheritent class that has variables, properties or + methods annotated with the [Autowire] attribute. + The order of the processing is that all inheritent classes are + processed before the actual class is processed. + + + + Using [Value] attribute for fine grained auto wiring + injection + + The [Autowire] attribute is wiring + byType and therefore not fine-grained enough for + some situations. You can also not inject values from loaded + PropertyPlaceHolder files. For these cases you can use the + [Value] attribute instead and this allows the + following situations: + + Inject an object by their Id: + + public class AutowireViaValue +{ + [Value("@(CiaoFoo)")] + public IFoo ciao; +} + + This works on private variables and also on properties. + + You can also use this scenario for auto wiring with a + method: + + public class AutowireMethodWithValue +{ + public IFoo ciao; + + [Autowired] + private void Prepare([Value("@(CiaoFoo)")] IFoo ciao) + { + this.ciao = ciao; + } +} + + You can also use the [Value] attribute to access properties from + a PropertyPlaceHolder configuration: + + public class AutowirePropertyPlaceHolder +{ + [Value("${greeting}")] + public string greeting; +} + + Basically you can use the full Spring Expression Language, here + we only showed these two examples of how you could use the + [Value] attribute. + + + + Using the plain [Qualifier] attribute to fine-grain the + auto wiring finding process + + The [Qualifier] attribute allows you to + define a qualification property on top of giving the object a name. + This can be used for defining several objects from the same type and + inject different values, later via auto wiring you can refer to this + definition property. Here an example. First we create our basic + object. + + public interface IFoo +{ + string Say(); +} + +public class SayFoo : IFoo +{ + private string _message; + + public string Say() + { + return "hello"; + } +} + + + Now we define our objects within our spring configuration file. + We create tow object that use the same base object type but we inject + different values. If we you use the [Autowire] we + would get an ObjectCreationException because we two + objects of the same type and most likely we would not got the object + we wanted. + + <object id="HelloFoo" type="Spring.Objects.Factory.Attributes.ByType.SayFoo, Spring.Core.Tests"> + <qualifier value="hello" /> + <property name="_message" value="Hello" /> +</object> + +<object id="CiaoFoo" type="Spring.Objects.Factory.Attributes.ByType.SayFoo, Spring.Core.Tests"> + <qualifier value="ciao" /> + <property name="_message" value="Hello" /> +</object> + + With the <qualifier> element in our + object definition we provided further information that we can use + during the auto wire process. See the code below and how to use the + [Qualifier] attribute to inject the object we want + without getting a ObjectCreationException. + + public class AutowireQithQualifier +{ + [Autowired] + [Qualifier("ciao")] + public IFoo Ciao { get; set; } +} + + + + Using a inherited [Qualifier] attribute with meta + properties + + The inherited QualifierAttribute class allows + you to define an object by more properties than a single qualifier + value. You can define objects by fine grained, own defined, properties + within a attribute. The first thing you need to do is to create a new + attribute derived from QualifierAttribute and + define your properties. + + public class DialectAttribute : QualifierAttribute +{ + private string _language = ""; + public string Language { get { return _language; } set { _language = value; } } +} + + The next step is to define your objects and the meta information + attached to them. The attributes you define within the + <qualifier> element are the same as your + peroperties in your created attribute. + + <object id="HelloFoo" type="Spring.Objects.Factory.Attributes.ByType.SayFoo, Spring.Core.Tests"> + <qualifier type="Spring.Objects.Factory.Attributes.ByQualifierAttribute.DialectAttribute"> + <attribute key="Language" value="English" /> + </qualifier> + <property name="_message" value="Hello" /> +</object> + +<object id="CiaoFoo" type="Spring.Objects.Factory.Attributes.ByType.SayFoo, Spring.Core.Tests"> + <qualifier type="Spring.Objects.Factory.Attributrf4res.ByQualifierAttribute.DialectAttribute"> + <attribute key="Language" value="Italian" /> + </qualifier> + <property name="_message" value="Ciao" /> +</object> + + Now you have defined your objects with new meta information. To + use this meta information within the auto wiring process you need to + add your created attribute as additional attribute to the [Autowire] + attributes in your code. The properties you use within the added + attribute will be matched with all registered objects. If they + properties are matching the object is used for injection. If more then + one object is found in the matching process and no object is defined + as primary a + ObjectCreationException is thrown. + + public class AutowireByMetaInformation +{ + [Autowired] + [Dialect(Language = "Italian")] + public IFoo ciao; +} + @@ -2719,24 +3048,24 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList an object deployed into the container. When enabling checking for unresolved dependencies all properties of the object must have an explicit values set for them in the object definition or have their - values set via autowiring. + values set via auto wiring. This feature useful when you want to ensure that all properties (or all properties of a certain type) are set on an object. An object often has default values for many properties, or some properties do not apply to all usage scenarios, so this feature is of limited use. You can - enable dependency checking per object, just as with the autowiring + enable dependency checking per object, just as with the auto wiring functionality. The default is not not check - dependencies. In XML-based configuration metadata, you specify + dependencies. In XML-based configuration meta data, you specify dependency checking via the dependency-check attribute in an object definition, which may have the following values.
Dependency checking modes - + - + @@ -2786,7 +3115,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList singletons. When a singleton object needs to collaborate with another singleton object, or a non-singleton object needs to collaborate with another non-singleton object, you typically handle the dependency by - defining one object as a property of the other. A problem arrises when + defining one object as a property of the other. A problem arises when the object lifecycles are different. Suppose singleton object A needs to use a non-singleton (prototype) object B, perhaps on each method invocation on A. The container only creates the singleton object A once, @@ -2834,7 +3163,7 @@ namespace Fiona.Apple } The preceding is not desirable, because the business code is aware - of and coupled to the Sring Framework. Method Injection, a somewhat + of and coupled to the Spring Framework. Method Injection, a somewhat advanced feature of the Spring IoC container, allows this use case to be handled in a clean fashion. @@ -2925,7 +3254,7 @@ namespace Fiona.Apple Method Injection is the ability to replace arbitrary methods in a managed object with another method implementation. - With XML-based configuration metadata, you can use the + With XML-based configuration meta data, you can use the replaced-method element to replace an existing method implementation with another, for a deployed object. Consider the following class, with a method ComputeValue, @@ -3014,7 +3343,7 @@ public class ReplacementComputeValue : IMethodReplacer indicates to Spring.NET that this object is itself a factory and the factories product, not the factory itself, is what will be associated with the object id. Factory objects are discussed further in + linkend="objects-factory-lifecycle-factoryobject"/> Setting a reference to the value of property. @@ -3040,7 +3369,7 @@ public class ReplacementComputeValue : IMethodReplacer Note that nested properties are supported for both instance and class property lookups. The IFactoryObject is discussed more generally in . + linkend="objects-factory-lifecycle-factoryobject"/>. Here's an example where a property path is used against another object instance. In this case, an inner object definition is used and @@ -3163,7 +3492,7 @@ public class ReplacementComputeValue : IMethodReplacer class. Additionally, it is sometimes necessary to invoke a method just to perform some sort of initialization.... while the mechanisms for handling object initialization have yet to be introduced (see ), these + linkend="objects-factory-lifecycle-initializingobject"/>), these mechanisms do not permit any arguments to be passed to any initialization method, and are confined to invoking an initialization method on the object that has just been instantiated by the container. @@ -3392,9 +3721,9 @@ public class MyClassFactory Object Scopes - + - + @@ -3529,7 +3858,7 @@ public class MyClassFactory prototype-scoped object is a replacement for the C# 'new' operator. All lifecycle management past that point must be handled by the client. (For details on the lifecycle of an object in the Spring container, see . + linkend="objects-factory-lifecycle"/>. @@ -3550,7 +3879,7 @@ public class MyClassFactory container is instantiating the singleton object and resolving and injecting its dependencies. If you need a new instance of a prototype object at runtime more than once, see . + linkend="objects-method-injection"/>. @@ -3627,9 +3956,9 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo Built-in <literal>TypeConverters</literal> - + - + @@ -3759,7 +4088,7 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo IApplicationContext is to use the custom configuration section handler TypeConverterSectionHandler This is demonstrated in - section + section An alternate approach, present for legacy reasons in the port of Spring.NET from the Java code base, is to use the object factory @@ -3880,7 +4209,7 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo can also achieve the same integration with the container without coupling your objects to Spring interfaces though the use of init-method and destroy-method - object definition metadata. + object definition meta data. Internally, Spring.NET uses implementations of the IObjectPostProcessor interface to process any call @@ -3888,9 +4217,9 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo custom features or other lifecycle behavior Spring.NET does not offer out-of-the-box, you can implement an IObjectPostProcessor yourself. For more information - see. + see. - + IInitializingObject / <literal>init-method</literal> @@ -3916,7 +4245,7 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo IInitializingObject interface because it unnecessarily coupules the code to Spring. Alternatively, specify an POJO initialization method. In the case of XML-based configuration - metadata, you use the init-method attribute to + meta data, you use the init-method attribute to specify the name of the method that has a void no-argument signature. For example, the following definition: @@ -3967,7 +4296,7 @@ public class AnotherExampleObject : IInitializingObject in the case with the IInitializingObject interface. However, you may also specify a destruction method that is not tied to the IDisposable interface. In the - case of XML-based configuration metadata, you use the + case of XML-based configuration meta data, you use the destroy-method attribute to specify the name of the method that has a void no-argument signature. For example, the following definition: @@ -3983,6 +4312,153 @@ public class AnotherExampleObject : IDisposable } } + + + [PostConstruct] and [PreDestroy] attribute driven lifecycle + management + + The InitDestroyAttributeObjectPostProcessor + recognizes lifecycle attributes such as [PostConstruct] and + [PreDestroy]. Introduced in Spring.Net 2.0, the support for these + attributes offers yet another alternative to those described in + initialization callbacks and destruction callbacks. Provided that the + InitDestroyAttributeObjectPostProcessor is + registered within the Spring ApplicationContext, a method carrying one + of these attributions is invoked at the same point in the lifecycle as + the corresponding Spring lifecycle interface method or explicitly + declared callback method. In the example below, the cache will be + pre-populated upon initialization and cleared upon destruction. + + The best way to illustrate the usage of this attribute is with + an example. + + public class MovieLister +{ + [PostConstruct] + public void Init() + { + // do some initialization here + } + + [PreDestroy] + public void Destroy() + { + // do some destruction here + } + + ... +}There is one last little piece of Spring configuration that + is required to actually 'switch on' this behaviour. Simply annotating + the methods of your classes is not enough to get this behaviour. You + need to enable a component that is aware of the + [PostContrsuct] and [PreDestroy] + attribute and that can process it appropriately. + + This component is the + InitDestroyAttributeObjectPostProcessor class. This + is a special IObjectPostProcessor implementation + that is [PostConstruct]- and + [PreDestroy]-aware and actually provides the + lifecycle logic. It is very easy to configure; simply drop the + following object definition into your Spring XML configuration. + + <object type="Spring.Objects.Factory.Attributes.InitDestroyAttributeObjectPostProcessor, Spring.Core"/>Finally, + you can configure an instance of the + InitDestroyAttributeObjectPostProcessor class to + look for other Attribute types. Simply plug it into the definition of + a InitDestroyAttributeObjectPostProcessor and you + are good to go, see example below: + + <object type="Spring.Objects.Factory.Attributes.InitDestroyAttributeObjectPostProcessor, Spring.Core"> + <property name="InitAttributeType" value="MyApp.Attributes.InitAttribute, MyApp"/> + <property name="DestroyAttributeType" value="MyApp.Attributes.DisposeAttribute, MyApp"/> +</object> + + + + Default initialization and destroy methods + + When you write initialization and destroy method callbacks that + do not use the Spring-specific IInitializingObject and IDisposable + callback interfaces, you typically write methods with names such as + Init(), Initialize(), + Dispose(), and so on. Ideally, the names of such + lifecycle callback methods are standardized across a project so that + all developers use the same method names and ensure + consistency. + + You can configure the Spring container to look for named + initialization and destroy callback method names on every object. This + means that you, as an application developer, can write your + application classes and use an initialization callback called + Init(), without having to configure an + init-method="Init" attribute with each object + definition. The Spring IoC container calls that method when the object + is created (and in accordance with the standard lifecycle callback + contract described previously). This feature also enforces a + consistent naming convention for initialization and destroy method + callbacks. + + Suppose that your initialization callback methods are named + Init() and destroy callback methods are named + Destroy(). Your class will resemble the class in + the following example. + + public class DefaultBlogService : IBlogService +{ + private IBlogDao _blogDao; + + public void Init() + { + if (_blogDao == null) { + throw new InvalidOperationException("The [_blogDao] property must be set."); + } + } + + public void Destroy() + { + // do some destruction work + } +}<objects default-init-method="Init" + defauly-destroy-method="Destroy"> + + <object id="BlogService" class="Examples.DefaultBlogService"> + <property name="_blogDao" ref="BlogDao" /> + </object> + +</objects>The presence of the + default-init-method attribute on the top-level + <objects/> element attribute causes the + Spring IoC container to recognize a method called + Init on objects as the initialization method + callback. When an object is created and assembled, if the object class + has such a method, it is invoked at the appropriate time. If the + object does not have such a method an + ObjectCreationException is thrown. To prevent this + for objects that do not have such a method you need to define an empty + init-method="" and/or + destroy-method="" attributes on the object + itself. + + Where existing object classes already have callback methods that + are named at variance with the convention, you can override the + default by specifying (in XML, that is) the method name using the + init-method and destroy-method + attributes on the <object/> itself. + + The Spring container guarantees that a configured initialization + callback is called immediately after an object is supplied with all + dependencies. Thus the initialization callback is called on the raw + object reference, which means that AOP interceptors and so forth are + not yet applied to the object. A target object is fully created first, + then an AOP proxy (for example) with its interceptor chain is applied. + If the target object and the proxy are defined separately, your code + can even interact with the raw target object, bypassing the proxy. + Hence, it would be inconsistent to apply the interceptors to the Init + method, because doing so would couple the lifecycle of the target + object with its proxy/interceptors and leave strange semantics when + your code interacts directly to the raw target object. + @@ -4011,7 +4487,7 @@ public class AnotherExampleObject : IDisposable IApplicationContext provide access to file resources, publishing application events, and accessing a IMessageSource. These additional features are - described in + described in IObjectNameAware @@ -4030,7 +4506,7 @@ public class AnotherExampleObject : IDisposable The callback is invoked after population of normal object properties but before an initialization callback such as IInitializingObject 's AfterPropertiesSet - method or a custom initalization method is invoked. + method or a custom initialization method is invoked. @@ -4052,7 +4528,7 @@ public class AnotherExampleObject : IDisposable with them on this level, instead configuring object definitions declaratively in something like the XmlApplicationContext. When you use XML-based - configuration metadata, you indicate a child object using the parent + configuration meta data, you indicate a child object using the parent attribute, specifying the parent object definition as the value of this attribute. @@ -4313,7 +4789,7 @@ Console.WriteLine (three == four); // prints 'false' IObjectFactoryPostProcessor (described below in the section entitled Customizing - configuration metadata with + configuration meta data with IObjectFactoryPostProcessors. Also, IObjectPostProcessors are scoped @@ -4435,7 +4911,7 @@ factory.AddObjectPostProcessor(pp); for auto-proxying)”. - + Example: Hello World, IObjectPostProcessor-style @@ -4523,7 +4999,7 @@ DEBUG - MovieApp Done. Example: the RequiredAttributeObjectPostProcessor - Using callback interfaces or annotations in conjunction with a + Using callback interfaces or attributes in conjunction with a custom IObjectPostProcessor implementation is a common means of extending the Spring IoC container. The [Required] attribute in the Spring.Objects.Factory.Attributes @@ -4606,7 +5082,7 @@ DEBUG - MovieApp Done. - Customizing configuration metadata with + <title>Customizing configuration meta data with <literal>IObjectFactoryPostProcessors</literal> The next extension point that we will look at is the @@ -4616,7 +5092,7 @@ DEBUG - MovieApp Done. IObjectFactoryPostProcessors operate on; that is to say, the Spring IoC container will allow IObjectFactoryPostProcessors to read the - configuration metadata and potentially change it before the container + configuration meta data and potentially change it before the container has actually instantiated any other objects. By implementing this interface, you will receive a callback after the all the object definitions have been loaded into the IoC container but before they have @@ -4641,7 +5117,7 @@ DEBUG - MovieApp Done. If you want to change the actual object instances (the objects - that are created from the configuration metadata), then you rather + that are created from the configuration meta data), then you rather need to use a IObjectObjectPostProcessor (described above in the section entitled Customizing objects with @@ -4660,7 +5136,7 @@ DEBUG - MovieApp Done. An object factory post-processor is executed manually (in the case of a IObjectFactory) or automatically (in the case of an IApplicationContext) to apply changes of some sort - to the configuration metadata that defines a container. Spring.NET + to the configuration meta data that defines a container. Spring.NET includes a number of pre-existing object factory post-processors, such as PropertyResourceConfigurer and PropertyPlaceHolderConfigurer, both described below @@ -4681,7 +5157,7 @@ cfg.setLocation(new FileSystemResource("ado.properties")); cfg.PostProcessObjectFactory(factory); This + xml:id="objects-factory-autodetect-objectfactorypostprocessors"/>This explicit registration step is not convenient, and this is one of the reasons why the various IApplicationContext implementations are preferred above plain @@ -4851,7 +5327,7 @@ cfg.PostProcessObjectFactory(factory); ApplicationContext for a non-lazy-init object.) - Similarly you can replace 'ref' and 'expression' metadata, as + Similarly you can replace 'ref' and 'expression' meta data, as shown below <object id="TestObject" type="Simple.TestObject, MyAssembly"> @@ -5055,7 +5531,7 @@ cfg.PostProcessObjectFactory(factory); - + Then you can use ${peggy_name}, ${peggy_age}, @@ -5327,7 +5803,7 @@ joan_age=35 The IFactoryObject concept and interface is used in a number of places within the Spring Framework. Some examples of its use is - described in for the + described in for the PropertyRetrievingFactoryObject and FieldRetrievingFactoryObject. An additional use of creating an custom IFactoryObject implementation is to retrieve an @@ -5365,7 +5841,7 @@ joan_age=35 IConfigurableFactoryObject implementions you - already have examples of in are + already have examples of in are WebServiceProxyFactory. @@ -5459,13 +5935,13 @@ joan_age=35 IObjectFactory capabilities in a lot more depth than the said feature matrix.) - +
Feature Matrix - + @@ -5758,7 +6234,7 @@ IApplicationContext context = </configuration> For an example showing type aliases for generic types see . + linkend="objects-creation-generic-types"/>. Another way is to define an object of the type Spring.Objects.Factory.Config.TypeAliasConfigurer @@ -5879,7 +6355,7 @@ IApplicationContext context = Spring.Context.Support.XmlApplicationContext. The name of the context can be used in conjunction with the service locator class, ContextRegistry, discussed in + linkend="objects-servicelocator"/> @@ -5997,7 +6473,7 @@ IApplicationContext context = ever used but provides programmatic ways to add messages to the source. The ResourceSetMessageSource is more interesting and an example is provided for in the distribution and discussed more - extensively in the section. The + extensively in the section. The ResourceSetMessageSource is configured by providing a list of ResourceManagers. When a message code is to be resolved, the list of ResourceManagers is searched to resolve the @@ -6090,7 +6566,7 @@ ctx.GetMessage("error.required", resources in a protocol independent way. The IApplicationContext has a method (GetResource(string)) to take care of this. Refer to - for more information on the string + for more information on the string format to use and the IResource abstraction in general. @@ -6371,7 +6847,7 @@ public class BlackListNotifier : IApplicationEventListener The class GenericApplicationContext can be used as a basis for creating an IApplicationContext implementation that read the container - metadata from sources other than XML. This could be by scanning objects in + meta data from sources other than XML. This could be by scanning objects in a .DLL for known attributes or a scripting language that leverages a DSL to create terse IObjectDefinitions. There is a class, Spring.Objects.Factory.Support.ObjectDefinitionBuilder offers some @@ -6388,7 +6864,7 @@ reader.LoadObjectDefinitions("assembly://Spring.Core.Tests/Spring.Context.Suppor ctx.Refresh(); The implementation of IObjectDefinitionReader is responsible for - creating the configuration metadata, i.e., implementations of + creating the configuration meta data, i.e., implementations of RootObjectDefinition, etc. Note a web version of this application class has not yet been implemented. @@ -6458,13 +6934,13 @@ ctx.Refresh(); Stereotype attributes Beginning with Spring 1.2, the [Repository] attribute was introduced - as a marker for any class that fulfills the role or stereotype of a + as a marker for any class that fulfils the role or stereotype of a repository (a.k.a. Data Access Object or DAO). Among the possibilities for leveraging such a marker is the automatic translation of exceptions as described in Exception Translation. - Spring 1.2 introduces further stereotype annotations: [Component] + Spring 1.2 introduces further stereotype attributes: [Component] and [Service]. [Component] serves as a generic stereotype for any Spring-managed component; whereas, [Repository] and [Service] serve as specializations of [Component] for more specific use cases (e.g., in the @@ -6473,7 +6949,7 @@ ctx.Refresh(); What this means is that you can annotate your component classes with [Component], but by annotating them with [Repository] or [Service] your classes are more properly suited for processing by tools or associating - with aspects. For example, these stereotype annotations make ideal targets + with aspects. For example, these stereotype attributes make ideal targets for pointcuts. Of course, it is also possible that [Repository] and [Service] may carry additional semantics in future releases of the Spring Framework. Thus, if you are making a decision between using [Component] or