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