Spring/spring-net
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Spell checking

Browse Source
This commit is contained in:
Thomas Trageser
2013-11-10 17:10:05 +00:00
parent 62aef6c05c
commit 1231e82334
1 changed files with 106 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files

212
doc/reference/src/objects.xml
View File

@@ -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.</para>
<note>
<para>Note that other ways to specify the metadata, such as attributes
<para>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.</para>
</note>
@@ -93,7 +93,7 @@
Configuration</link> for more details.</para>
<para>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.</para>
@@ -104,22 +104,22 @@
</mediaobject>
<sect2 xml:id="objects-configuration-metadata">
<title>Configuration metadata</title>
<title>Configuration meta data</title>
<para>As the preceding diagram shows, the Spring IoC container consumes
a form of <emphasis>configuration metadata</emphasis>; this
configuration metadata represents how you as an application developer
a form of <emphasis>configuration meta data</emphasis>; 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</para>
<note>
<para>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
<para>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.</para>
</note>
@@ -138,7 +138,7 @@
domain objects.</para>
<para>The following example shows the basic structure of XML-based
configuration metadata:</para>
configuration meta data:</para>
<programlisting language="myxml">&lt;objects xmlns="http://www.springframework.net"&gt;
@@ -181,7 +181,7 @@
<para>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.</para>
<programlisting language="csharp">IApplicationContext context = new XmlApplicationContext("services.xml", "data-access.xml");
@@ -228,7 +228,7 @@
linkend="objects-dependencies">Dependencies</link>.</para>
<sect3>
<title>Loading configuration metadata from non-default resource
<title>Loading configuration meta data from non-default resource
locations</title>
<para>In the previous example the configuration resources are assumed
@@ -254,7 +254,7 @@
<para>After you learn about Spring's IoC container, you may want to
know more about Spring's <classname><link
ns6:href="http://www.springframework.net/doc-latest/api/net-2.0/html/Spring.Core~Spring.Core.IO.IResource.html">IResource</link></classname>
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 <xref linkend="resources"/></para>
</note>
@@ -397,7 +397,7 @@
</sect3>
<sect3 xml:id="objects-factory-xml-import">
<title>Composing XML-based configuration metadata</title>
<title>Composing XML-based configuration meta data</title>
<para>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();
<title>Object definition overview</title>
<para>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.</para>
<para>Within the container itself, these object definitions are
represented as <classname>IObjectDefinition</classname> objects, which
contain (among other information) the following metadata: <itemizedlist
contain (among other information) the following meta data: <itemizedlist
spacing="compact">
<listitem>
<para><emphasis>A type name</emphasis>: typically the actual
@@ -517,7 +517,7 @@ IList userList = service.GetUserNames();
</listitem>
</itemizedlist></para>
<para>This metadata translates to a set of properties that make up each
<para>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 <table frame="all">
<title>Object definition explanation</title>
@@ -607,7 +607,7 @@ IList userList = service.GetUserNames();
registration through the methods
<literal>RegisterSingleton(..)</literal> and
<literal>RegisterObjectDefinition(..)</literal>. However, typical
applications work soley with objects defined through metadata object
applications work soley with objects defined through meta data object
definitions.</para>
<sect3 xml:id="objects-objectname">
@@ -631,7 +631,7 @@ IList userList = service.GetUserNames();
when applying advice to a set of objects related by name.</para>
</sidebar>
<para>When using XML-based configuration metadata, you use the
<para>When using XML-based configuration meta data, you use the
<literal>'id'</literal> and/or <literal>'name'</literal>attributes to
specify the object identifier(s). The <literal>'id'</literal>
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
&lt;alias/&gt; element to accomplish this.</para>
<programlisting language="myxml"> &lt;alias name="fromName" alias="toName"/&gt;</programlisting>
@@ -683,14 +683,14 @@ IList userList = service.GetUserNames();
<literal>fromName</literal>, may also after the use of this alias
definition, be referred to as <literal>toName</literal>.</para>
<para>For example, the configuration metadata for subsystem A may
<para>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:</para>
configuration meta data the following aliases definitions:</para>
<programlisting language="myxml">&lt;alias name="SubsystemA-DbProvider" alias="SubsystemB-DbProvider"/&gt;
&lt;alias name="SubsystemA-DbProvider" alias="MyApp-DbProvider"/&gt;</programlisting>
@@ -708,10 +708,10 @@ IList userList = service.GetUserNames();
<para>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.</para>
<para>If you are using XML-based configuration metadata, you can specify
<para>If you are using XML-based configuration meta data, you can specify
the type of object that is to be instantiated in the
<literal>'type'</literal> attribute of the
<literal>&lt;object/&gt;</literal> 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.</para>
<para>With XML-based configuration metadata you can specify your
<para>With XML-based configuration meta data you can specify your
object class as follows: <programlisting language="myxml">&lt;object id="exampleObject" type="Examples.ExampleObject, ExamplesLibrary"/&gt;</programlisting></para>
<para>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
<sect3 xml:id="objects-di-examples">
<title>Examples of dependency injection</title>
<para>First, an example of using XML-based configuration metadata for
<para>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:<programlisting language="myxml">&lt;object id="exampleObject" type="Examples.ExampleObject, ExamplesLibrary"&gt;
@@ -1658,7 +1658,7 @@ public class MixedIocObject
<para>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
<literal>&lt;property/&gt;</literal> and
&lt;<literal>constructor-arg/&gt;</literal> elements for this
purpose.</para>
@@ -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
<literal>targetName</literal> 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.</para>
@@ -1749,7 +1749,7 @@ public class MixedIocObject
&lt;/property&gt;</programlisting>
<para>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.</para>
</sect4>
</sect3>
@@ -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.</para>
<para><emphasis>The value of a Dictionary entry, or a set value, can
@@ -1921,7 +1921,7 @@ public class MixedIocObject
for <literal>IList&lt;T&gt;</literal> and the XML attributes
<literal>key-type</literal> and <literal>value-type</literal> for
<literal>IDictionary&lt;TKey, TValue&gt;</literal>. 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 <xref linkend="objects-type-conversion"/> for more
@@ -2086,13 +2086,13 @@ public class MixedIocObject
<programlisting>administrator=administrator@example.com // from parent
sales=sales@example.com // from child
support=support@example.co.uk // overriden by child</programlisting>
support=support@example.co.uk // overridden by child</programlisting>
<para>The child Properties collection's value set inherits all
property elements from the parent
<literal>&lt;name-values/&gt;</literal>, 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
<literal>&lt;list/&gt;</literal>,
<literal>&lt;dictionary/&gt;</literal>, and
<literal>&lt;set/&gt;</literal> collection types. In the specific case
@@ -2112,7 +2112,7 @@ support=support@example.co.uk // overriden by child</programlisting>
<title>Null and empty values</title>
<para>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 ("")</para>
<programlisting>&lt;object type="Examples.ExampleObject, ExamplesLibrary"&gt;
@@ -2143,7 +2143,7 @@ support=support@example.co.uk // overriden by child</programlisting>
<para>An indexer lets you set and get values from a collection using a
familiar bracket <literal>[]</literal> 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 <xref linkend="expressions"/>
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
<para>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 <literal>&lt;ref/&gt;</literal> 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
<literal>depends-on</literal> 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 &lt;object/&gt; element. The
following values are allowed:</para>
@@ -2706,49 +2706,49 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList
<itemizedlist>
<listitem>
<para>Abandon autowiring in favor of explicit wiring.</para>
<para>Abandon auto wiring in favour of explicit wiring.</para>
</listitem>
<listitem>
<para>Avoid autowiring for a bean definition by setting its
<para>Avoid auto wiring for an object definition by setting its
autowire-candidate attributes to false as described in the next
section.</para>
</listitem>
<listitem>
<para>Designate a single bean definition as the primary candidate by
<para>Designate a single object definition as the primary candidate by
setting the primary attribute of its &lt;object/&gt; element to
true.</para>
</listitem>
<listitem>
<para>Implement the more fine-grained control available with
annotation-based configuration.</para>
attribute-based configuration.</para>
</listitem>
</itemizedlist>
<para>When deciding whether to use autowiring, there is no wrong or
<para>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.</para>
<sect3>
<title>Excluding a bean from autowiring</title>
<title>Excluding an object from auto wiring</title>
<para>On a per-bean basis, you can exclude a bean from autowiring. In
<para>On a per-object basis, you can exclude an object from auto wiring. In
Spring's XML format, set the <literal>autowire-candidate</literal>
attribute of the <literal>&lt;object/&gt;</literal> element to
<literal>false</literal>; 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
<literal>[Autowired]</literal>).</para>
<para>You can also limit autowire candidates based on pattern-matching
<para>You can also limit auto wire candidates based on pattern-matching
against object names. The top-level
<literal>&lt;objects/&gt;</literal> element accepts one or more
patterns within its <literal>default-autowire-candidates</literal>
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 <emphasis>Repository</emphasis>, provide a
value of <emphasis>*Repository</emphasis>. 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.</para>
<para>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.</para>
</sect3>
@@ -2770,7 +2770,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList
<para>The <literal>[Autowire]</literal> attribute in the
<literal>Spring.Objects.Factory.Attributes</literal> 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 <emphasis>byType</emphasis> 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.</para>
<para>To get the <literal>[Autowire]</literal> 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.</para>
<para><programlisting language="myxml">&lt;object type="Spring.Objects.Factory.Attributes.RequiredAttributeObjectPostProcessor, Spring.Core"/&gt;</programlisting></para>
<para>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
<para>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 <literal>ObjectCreationException</literal>.
To prevent or control this situation you can use the
<literal>primary</literal> attribute in the
<literal>&lt;object&gt;</literal> defintion, later you will see an
<literal>&lt;object&gt;</literal> definition, later you will see an
example for this situation.</para>
<programlisting language="csharp">public class SomeObject
@@ -2806,7 +2806,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList
...
} </programlisting>
<para>You can also use the autowire attribute to inject into methods.
<para>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.</para>
@@ -2837,7 +2837,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList
<para><programlisting language="myxml">&lt;object id="HelloFoo" type="Spring.Objects.Factory.Attributes.ByType.HelloFoo, Spring.Core.Tests"
primary="true"/&gt;</programlisting></para>
<para>You can also use the autowire attribute for injection in to a
<para>You can also use the auto wire attribute for injection in to a
List&lt;T&gt;, ISet&lt;T&gt; or Dictionary&lt;string, T&gt; 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&lt;T&gt;,
@@ -2875,12 +2875,12 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList
<para>The <literal>[Autowire]</literal> attribute is also processed in
the case of an inheritent class that has variables, properties or
methods annotated with the <literal>[Autowire]</literal> 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.</para>
</sect3>
<sect3>
<title>Using [Value] attribute for fine grained autowiring
<title>Using [Value] attribute for fine grained auto wiring
injection</title>
<para>The <literal>[Autowire]</literal> attribute is wiring
@@ -2900,7 +2900,7 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList
<para>This works on private variables and also on properties.</para>
<para>You can also use this scenario for autowiring with a
<para>You can also use this scenario for auto wiring with a
method:</para>
<programlisting language="csharp">public class AutowireMethodWithValue
@@ -2930,12 +2930,12 @@ source.OnClick(); // First eventListener1.HandleEvent is invoked, then eventList
<sect3>
<title>Using the plain [Qualifier] attribute to fine-grain the
autowiring finding process</title>
auto wiring finding process</title>
<para>The <literal>[Qualifier]</literal> 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.</para>
@@ -2973,8 +2973,8 @@ public class SayFoo : IFoo
&lt;/object&gt; </programlisting>
<para>With the <literal>&lt;qualifier&gt;</literal> 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
<literal>[Qualifier]</literal> attribute to inject the object we want
without getting a <literal>ObjectCreationException</literal>.</para>
@@ -3023,8 +3023,8 @@ public class SayFoo : IFoo
&lt;/object&gt;</programlisting>
<para>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.</para>
values set via auto wiring.</para>
<para>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 <emphasis>not</emphasis> check
dependencies. In XML-based configuration metadata, you specify
dependencies. In XML-based configuration meta data, you specify
dependency checking via the <literal>dependency-check</literal>
attribute in an object definition, which may have the following values.
<table frame="all">
@@ -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
}</programlisting>
<para>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.</para>
@@ -3254,7 +3254,7 @@ namespace Fiona.Apple
Method Injection is the ability to replace arbitrary methods in a
managed object with another method implementation.</para>
<para>With XML-based configuration metadata, you can use the
<para>With XML-based configuration meta data, you can use the
<literal>replaced-method</literal> element to replace an existing
method implementation with another, for a deployed object. Consider
the following class, with a method <literal>ComputeValue</literal>,
@@ -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
<literal>init-method</literal> and <literal>destroy-method</literal>
object definition metadata.</para>
object definition meta data.</para>
<para>Internally, Spring.NET uses implementations of the
<literal>IObjectPostProcessor</literal> interface to process any call
@@ -4245,7 +4245,7 @@ public sealed class Font : MarshalByRefObject, ICloneable, ISerializable, IDispo
<literal>IInitializingObject</literal> 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 <literal>init-method</literal> attribute to
meta data, you use the <literal>init-method</literal> attribute to
specify the name of the method that has a void no-argument signature.
For example, the following definition:</para>
@@ -4296,7 +4296,7 @@ public class AnotherExampleObject : IInitializingObject
in the case with the <classname>IInitializingObject</classname>
interface. However, you may also specify a destruction method that is
not tied to the <classname>IDisposable</classname> interface. In the
case of XML-based configuration metadata, you use the
case of XML-based configuration meta data, you use the
<literal>destroy-method</literal> attribute to specify the name of the
method that has a void no-argument signature. For example, the
following definition:</para>
@@ -4314,7 +4314,7 @@ public class AnotherExampleObject : IDisposable
</sect3>
<sect3>
<title>[PostConstruct] and [Predestroy] attribute driven lifecycle
<title>[PostConstruct] and [PreDestroy] attribute driven lifecycle
management</title>
<para>The <literal>InitDestroyAttributeObjectPostProcessor</literal>
@@ -4324,7 +4324,7 @@ public class AnotherExampleObject : IDisposable
initialization callbacks and destruction callbacks. Provided that the
<literal>InitDestroyAttributeObjectPostProcessor</literal> 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.</para>
@@ -4348,8 +4348,8 @@ public class AnotherExampleObject : IDisposable
...
}</programlisting>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
<literal>[PostContrsuct]</literal> and <literal>[PreDestroy]</literal>
attribute and that can process it appropriately.</para>
@@ -4506,7 +4506,7 @@ public class AnotherExampleObject : IDisposable
<para>The callback is invoked after population of normal object
properties but before an initialization callback such as
<classname>IInitializingObject</classname> 's AfterPropertiesSet
method or a custom initalization method is invoked.</para>
method or a custom initialization method is invoked.</para>
</sect3>
</sect2>
</sect1>
@@ -4528,7 +4528,7 @@ public class AnotherExampleObject : IDisposable
with them on this level, instead configuring object definitions
declaratively in something like the
<literal>XmlApplicationContext.</literal> 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.</para>
@@ -4789,7 +4789,7 @@ Console.WriteLine (three == four); // prints 'false'
<literal>IObjectFactoryPostProcessor</literal> (described below in the
section entitled <link
linkend="objects-factory-customizing-factory-postprocessors">Customizing
configuration metadata with
configuration meta data with
IObjectFactoryPostProcessors.</link></para>
<para>Also, <literal>IObjectPostProcessors</literal> are scoped
@@ -4999,7 +4999,7 @@ DEBUG - MovieApp Done.</programlisting>
<sect3 xml:id="object-factory-extension-opp-examplesrapp">
<title>Example: the RequiredAttributeObjectPostProcessor</title>
<para>Using callback interfaces or annotations in conjunction with a
<para>Using callback interfaces or attributes in conjunction with a
custom IObjectPostProcessor implementation is a common means of
extending the Spring IoC container. The <literal>[Required]</literal>
attribute in the <literal>Spring.Objects.Factory.Attributes</literal>
@@ -5082,7 +5082,7 @@ DEBUG - MovieApp Done.</programlisting>
</sect2>
<sect2 xml:id="objects-factory-customizing-factory-postprocessors">
<title>Customizing configuration metadata with
<title>Customizing configuration meta data with
<literal>IObjectFactoryPostProcessors</literal></title>
<para>The next extension point that we will look at is the
@@ -5092,7 +5092,7 @@ DEBUG - MovieApp Done.</programlisting>
<literal>IObjectFactoryPostProcessors</literal> operate on; that is to
say, the Spring IoC container will allow
<literal>IObjectFactoryPostProcessors</literal> 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.</programlisting>
<note>
<para>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 <literal>IObjectObjectPostProcessor</literal> (described
above in the section entitled <link
linkend="objects-factory-customizing">Customizing objects with
@@ -5136,7 +5136,7 @@ DEBUG - MovieApp Done.</programlisting>
<para>An object factory post-processor is executed manually (in the case
of a <literal>IObjectFactory</literal>) or automatically (in the case of
an <literal>IApplicationContext</literal>) 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 <literal>PropertyResourceConfigurer</literal> and
<literal>PropertyPlaceHolderConfigurer</literal>, both described below
@@ -5327,7 +5327,7 @@ cfg.PostProcessObjectFactory(factory);</programlisting></para>
<literal>ApplicationContext</literal> for a non-lazy-init
object.)</para>
<para>Similarly you can replace 'ref' and 'expression' metadata, as
<para>Similarly you can replace 'ref' and 'expression' meta data, as
shown below</para>
<programlisting language="myxml">&lt;object id="TestObject" type="Simple.TestObject, MyAssembly"&gt;
@@ -6847,7 +6847,7 @@ public class BlackListNotifier : IApplicationEventListener
<para>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();</programlisting>
<para>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.</para>
@@ -6934,13 +6934,13 @@ ctx.Refresh();</programlisting>
<title>Stereotype attributes</title>
<para>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 <link linkend="orm-hibernate-straight-ex">Exception
Translation.</link></para>
<para>Spring 1.2 introduces further stereotype annotations: [Component]
<para>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();</programlisting>
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