From 13ac7196b38534b338ccd4fc95341bb868129369 Mon Sep 17 00:00:00 2001 From: Thomas Trageser Date: Tue, 9 Oct 2012 21:39:01 +0100 Subject: [PATCH 1/4] Updated documentation for objects default-init-method and default-destroy-method; add section for InitDestroyObjectPostProcessor --- doc/reference/src/index.xml | 8 +- doc/reference/src/objects.xml | 274 ++++++++++++++++++++++++++-------- 2 files changed, 215 insertions(+), 67 deletions(-) diff --git a/doc/reference/src/index.xml b/doc/reference/src/index.xml index 78a9b353..10a74282 100644 --- a/doc/reference/src/index.xml +++ b/doc/reference/src/index.xml @@ -67,8 +67,8 @@ The Spring.NET Framework Reference Documentation - Version 1.3.2 - Last Updated August 1, 2011 (Latest documentation) + Version 2.0.0 + Last Updated October 10, 2012 (Latest documentation) Mark @@ -118,6 +118,10 @@ Stephen Bohlen + + Thomas + Trageser + The Spring Java Team diff --git a/doc/reference/src/objects.xml b/doc/reference/src/objects.xml index c135e961..94e4848a 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 @@ -100,7 +99,7 @@ - + @@ -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. @@ -256,7 +255,7 @@ know more about Spring's IResource abstraction to load metadata from other locations as desribed below - and alsoin the chapter + 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,14 +386,14 @@ </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 @@ -524,9 +523,9 @@ IList userList = service.GetUserNames(); 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 - + @@ -764,7 +761,7 @@ IList userList = service.GetUserNames(); 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. @@ -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. @@ -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. @@ -1927,7 +1924,7 @@ public class MixedIocObject collection are automaticaly 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 @@ -2147,7 +2144,7 @@ support=support@example.co.uk // overriden by child 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 + 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 @@ -2568,9 +2565,9 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList Autowiring modes - + - + @@ -2734,9 +2731,9 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList Dependency checking modes - + - + @@ -3014,7 +3011,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 +3037,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 +3160,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 +3389,9 @@ public class MyClassFactory Object Scopes - + - + @@ -3529,7 +3526,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 +3547,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 +3624,9 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo Built-in <literal>TypeConverters</literal> - + - + @@ -3759,7 +3756,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 @@ -3888,9 +3885,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> @@ -3983,6 +3980,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 annotations 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 behavior. Simply annotating + the methods of your classes is not enough to get this behavior. 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 +4155,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 @@ -4435,7 +4579,7 @@ factory.AddObjectPostProcessor(pp); for auto-proxying)”. - + Example: Hello World, IObjectPostProcessor-style @@ -4681,7 +4825,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 @@ -5055,7 +5199,7 @@ cfg.PostProcessObjectFactory(factory); - + Then you can use ${peggy_name}, ${peggy_age}, @@ -5327,7 +5471,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 +5509,7 @@ joan_age=35 IConfigurableFactoryObject implementions you - already have examples of in are + already have examples of in are WebServiceProxyFactory. @@ -5459,13 +5603,13 @@ joan_age=35 IObjectFactory capabilities in a lot more depth than the said feature matrix.) - + Feature Matrix - + @@ -5758,7 +5902,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 +6023,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 +6141,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 +6234,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. From 187cd43729900c7cc4b203a6581372a0b77c937a Mon Sep 17 00:00:00 2001 From: Thomas Trageser Date: Tue, 30 Oct 2012 21:52:41 +0000 Subject: [PATCH 2/4] Updated documentation and add section for using the [Autowire] attribute inlcuding [Value] and [Qualifier] --- doc/reference/src/objects.xml | 326 ++++++++++++++++++++++++++++++++++ 1 file changed, 326 insertions(+) diff --git a/doc/reference/src/objects.xml b/doc/reference/src/objects.xml index 94e4848a..b34d9920 100644 --- a/doc/reference/src/objects.xml +++ b/doc/reference/src/objects.xml @@ -2702,11 +2702,337 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList arbitrarily resolved. Instead, if no unique object definition is available, an Exception will be thrown. + In the latter scenario, you have several options: + + + + Abandon autowiring in favor of explicit wiring. + + + + Avoid autowiring for a bean definition by setting its + autowire-candidate attributes to false as described in the next + section. + + + + Designate a single bean definition as the primary candidate by + setting the primary attribute of its <object/> element to + true. + + + + Implement the more fine-grained control available with + annotation-based configuration. + + + When deciding whether to use autowiring, 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 definitions. + + + Excluding a bean from autowiring + + On a per-bean basis, you can exclude a bean from autowiring. 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 autowiring infrastructure (including + annotation style configurations such as + [Autowired]). + + You can also limit autowire 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 autowire 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 autowiring. It does not mean that an + excluded object cannot itself be configured using autowiring. Rather, + the object itself is not a candidate for autowiring 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 autowire 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 autowire post processer into your spring configuration + file. + + <object type="Spring.Objects.Factory.Attributes.RequiredAttributeObjectPostProcessor, Spring.Core"/> + + To use the autowire attribute on a variable, it can be private + or public. The folowing code shows how to use the attribute. The post + processer 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> defintion, 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 autowire 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 autowire 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; } +} + + + + Using [Value] attribute for fine grained autowiring + 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 autowiring 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 + autowiring 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 autowiring 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 defintion we provided further information that we can use + during the autowire 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 autowiring process you need to + add your created attribute as additional annotation 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; +} + From 71bd86e0c211f589bc9d030f24a53a9772f563f1 Mon Sep 17 00:00:00 2001 From: Thomas Trageser Date: Wed, 31 Oct 2012 23:32:02 +0000 Subject: [PATCH 3/4] Wrong language setting for XML documentation; added information about autowire inheritence --- doc/reference/src/objects.xml | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/doc/reference/src/objects.xml b/doc/reference/src/objects.xml index b34d9920..bf272b49 100644 --- a/doc/reference/src/objects.xml +++ b/doc/reference/src/objects.xml @@ -2781,7 +2781,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList need to add the autowire post processer into your spring configuration file. - <object type="Spring.Objects.Factory.Attributes.RequiredAttributeObjectPostProcessor, Spring.Core"/> + <object type="Spring.Objects.Factory.Attributes.RequiredAttributeObjectPostProcessor, Spring.Core"/> To use the autowire attribute on a variable, it can be private or public. The folowing code shows how to use the attribute. The post @@ -2834,7 +2834,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList primary, the container will throw a ObjectCreationException. - <object id="HelloFoo" type="Spring.Objects.Factory.Attributes.ByType.HelloFoo, Spring.Core.Tests" + <object id="HelloFoo" type="Spring.Objects.Factory.Attributes.ByType.HelloFoo, Spring.Core.Tests" primary="true"/> You can also use the autowire attribute for injection in to a @@ -2845,7 +2845,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList objects injected. For the dictionary type the key is the registered name of the object. - public class AutowireLists + public class AutowireLists { [Autowired] public IList<IFoo> foosList; @@ -2866,11 +2866,17 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList required and therefore will not throw an ObjectCreationException. - public class AutowirePropertyNotRequired + 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 inhertent classes are + processed before the actual class is processed. @@ -2956,7 +2962,7 @@ public class SayFoo : IFoo 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"> + <object id="HelloFoo" type="Spring.Objects.Factory.Attributes.ByType.SayFoo, Spring.Core.Tests"> <qualifier value="hello" /> <property name="_message" value="Hello" /> </object> @@ -3002,7 +3008,7 @@ public class SayFoo : IFoo <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"> + <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> From 1231e82334b8543f44453c6adea77d6f45b3e5b0 Mon Sep 17 00:00:00 2001 From: Thomas Trageser Date: Sun, 10 Nov 2013 17:10:05 +0000 Subject: [PATCH 4/4] Spell checking --- doc/reference/src/objects.xml | 212 +++++++++++++++++----------------- 1 file changed, 106 insertions(+), 106 deletions(-) diff --git a/doc/reference/src/objects.xml b/doc/reference/src/objects.xml index 8c8b53c5..e180dbd1 100644 --- a/doc/reference/src/objects.xml +++ b/doc/reference/src/objects.xml @@ -69,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. @@ -93,7 +93,7 @@ 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. @@ -104,22 +104,22 @@ - 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. @@ -138,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"> @@ -181,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"); @@ -228,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 @@ -254,7 +254,7 @@ 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 + abstraction to load meta data from other locations as desribed below and alsoin the chapter @@ -397,7 +397,7 @@ - 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 @@ -484,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 @@ -517,7 +517,7 @@ 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 @@ -607,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. @@ -631,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 @@ -673,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"/> @@ -683,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"/> @@ -708,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 @@ -755,7 +755,7 @@ 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 @@ -1046,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 @@ -1503,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"> @@ -1658,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. @@ -1721,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. @@ -1749,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. @@ -1763,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 @@ -1897,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 @@ -1921,7 +1921,7 @@ 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 @@ -2086,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 @@ -2112,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"> @@ -2143,7 +2143,7 @@ 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 + 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 @@ -2464,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 @@ -2557,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: @@ -2706,49 +2706,49 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList - Abandon autowiring in favor of explicit wiring. + Abandon auto wiring in favour of explicit wiring. - Avoid autowiring for a bean definition by setting its + Avoid auto wiring for an object definition by setting its autowire-candidate attributes to false as described in the next section. - Designate a single bean definition as the primary candidate by + 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 - annotation-based configuration. + attribute-based configuration. - When deciding whether to use autowiring, there is no wrong or + 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 a bean from autowiring + Excluding an object from auto wiring - On a per-bean basis, you can exclude a bean from autowiring. In + 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 autowiring infrastructure (including - annotation style configurations such as + definition unavailable to the auto wiring infrastructure (including + attribute style configurations such as [Autowired]). - You can also limit autowire candidates based on pattern-matching + 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 autowire candidate status to any + 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 @@ -2758,9 +2758,9 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList not apply. These techniques are useful for objects that you never want to - be injected into other objects by autowiring. It does not mean that an - excluded object cannot itself be configured using autowiring. Rather, - the object itself is not a candidate for autowiring other + 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. @@ -2770,7 +2770,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList 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 autowire configuration described + 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 @@ -2778,19 +2778,19 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList inject. To get the [Autowire] attribute working you - need to add the autowire post processer into your spring configuration + 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 autowire attribute on a variable, it can be private - or public. The folowing code shows how to use the attribute. The post - processer will try to find a registered object that is from the + 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> defintion, later you will see an + <object> definition, later you will see an example for this situation. public class SomeObject @@ -2806,7 +2806,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList ... } - You can also use the autowire attribute to inject into methods. + 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. @@ -2837,7 +2837,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList <object id="HelloFoo" type="Spring.Objects.Factory.Attributes.ByType.HelloFoo, Spring.Core.Tests" primary="true"/> - You can also use the autowire attribute for injection in to a + 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>, @@ -2875,12 +2875,12 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList 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 inhertent classes are + The order of the processing is that all inheritent classes are processed before the actual class is processed. - Using [Value] attribute for fine grained autowiring + <title>Using [Value] attribute for fine grained auto wiring injection The [Autowire] attribute is wiring @@ -2900,7 +2900,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList This works on private variables and also on properties. - You can also use this scenario for autowiring with a + You can also use this scenario for auto wiring with a method: public class AutowireMethodWithValue @@ -2930,12 +2930,12 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList Using the plain [Qualifier] attribute to fine-grain the - autowiring finding process + 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 autowiring you can refer to this + inject different values, later via auto wiring you can refer to this definition property. Here an example. First we create our basic object. @@ -2973,8 +2973,8 @@ public class SayFoo : IFoo </object> With the <qualifier> element in our - object defintion we provided further information that we can use - during the autowire process. See the code below and how to use the + 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. @@ -3023,8 +3023,8 @@ public class SayFoo : IFoo </object> Now you have defined your objects with new meta information. To - use this meta information within the autowiring process you need to - add your created attribute as additional annotation to the [Autowire] + 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 @@ -3048,15 +3048,15 @@ public class SayFoo : IFoo 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.
@@ -3115,7 +3115,7 @@ public class SayFoo : IFoo 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, @@ -3163,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. @@ -3254,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, @@ -4209,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 @@ -4245,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: @@ -4296,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: @@ -4314,7 +4314,7 @@ public class AnotherExampleObject : IDisposable - [PostConstruct] and [Predestroy] attribute driven lifecycle + <title>[PostConstruct] and [PreDestroy] attribute driven lifecycle management The InitDestroyAttributeObjectPostProcessor @@ -4324,7 +4324,7 @@ public class AnotherExampleObject : IDisposable initialization callbacks and destruction callbacks. Provided that the InitDestroyAttributeObjectPostProcessor is registered within the Spring ApplicationContext, a method carrying one - of these annotations is invoked at the same point in the lifecycle as + 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. @@ -4348,8 +4348,8 @@ public class AnotherExampleObject : IDisposable ... }There is one last little piece of Spring configuration that - is required to actually 'switch on' this behavior. Simply annotating - the methods of your classes is not enough to get this behavior. You + 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. @@ -4506,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. @@ -4528,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. @@ -4789,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 @@ -4999,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 @@ -5082,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 @@ -5092,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 @@ -5117,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 @@ -5136,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 @@ -5327,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"> @@ -6847,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 @@ -6864,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. @@ -6934,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 @@ -6949,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