Fix typo in classpath scanning reference doc

Issue: SPR-8842
This commit is contained in:
Chris Beams 2011-11-16 23:32:38 +00:00
parent 7918810366
commit 1d5ca80924
1 changed files with 15 additions and 17 deletions

View File

@ -4,23 +4,21 @@
<section id="beans-classpath-scanning">
<title>Classpath scanning and managed components</title>
<!-- MLP: Beverly to review paragraph -->
<para>Most examples foo bar in this chapter use XML to specify the
configuration metadata that produces each
<interfacename>BeanDefinition</interfacename> within the Spring container.
The previous section (<xref linkend="beans-annotation-config"/>)
demonstrates how to provide a lot of the configuration metadata through
source-level annotations. Even in those examples, however, the "base" bean
definitions are explicitly defined in the XML file, while the annotations
only drive the dependency injection. This section describes an option for
implicitly detecting the <emphasis>candidate components</emphasis> by
scanning the classpath. Candidate components are classes that match against
a filter criteria and have a corresponding bean definition registered with
the container. This removes the need to use XML to perform bean
registration, instead you can use annotations (for example @Component),
AspectJ type expressions, or your own custom filter criteria to select which
classes will have bean definitions registered with the container.</para>
<para>Most examples in this chapter use XML to specify the configuration
metadata that produces each <interfacename>BeanDefinition</interfacename>
within the Spring container. The previous section
(<xref linkend="beans-annotation-config"/>) demonstrates how to provide a
lot of the configuration metadata through source-level annotations. Even
in those examples, however, the "base" bean definitions are explicitly
defined in the XML file, while the annotations only drive the dependency
injection. This section describes an option for implicitly detecting the
<emphasis>candidate components</emphasis> by scanning the classpath.
Candidate components are classes that match against a filter criteria and
have a corresponding bean definition registered with the container. This
removes the need to use XML to perform bean registration, instead you can
use annotations (for example @Component), AspectJ type expressions, or your
own custom filter criteria to select which classes will have bean
definitions registered with the container.</para>
<note>
<para>Starting with Spring 3.0, many features provided by the <ulink