Consistent references to annotation-based autowiring

Author: jhoeller

framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc

@@ -317,8 +317,8 @@ exposed based on security policies in some environments -- for example, standalo
 JDK 1.7.0_45 and higher (which requires 'Trusted-Library' setup in your manifests -- see
 {stackoverflow-questions}/19394570/java-jre-7u45-breaks-classloader-getresources).
 
-On JDK 9's module path (Jigsaw), Spring's classpath scanning generally works as expected.
-However, make sure that your component classes are exported in your `module-info`
+On the module path (Java Module System), Spring's classpath scanning generally works as
+expected. However, make sure that your component classes are exported in your `module-info`
 descriptors. If you expect Spring to invoke non-public members of your classes, make
 sure that they are 'opened' (that is, that they use an `opens` declaration instead of an
 `exports` declaration in your `module-info` descriptor).
@@ -751,7 +751,7 @@ and bean definition show.
 TIP: If you run into naming conflicts due to multiple autodetected components having the
 same non-qualified class name (i.e., classes with identical names but residing in
 different packages), you may need to configure a `BeanNameGenerator` that defaults to the
-fully qualified class name for the generated bean name. As of Spring Framework 5.2.3, the
+fully qualified class name for the generated bean name. The
 `FullyQualifiedAnnotationBeanNameGenerator` located in package
 `org.springframework.context.annotation` can be used for such purposes.
 
@@ -920,7 +920,8 @@ Kotlin::
 [[beans-scanning-qualifiers]]
 == Providing Qualifier Metadata with Annotations
 
-The `@Qualifier` annotation is discussed in xref:core/beans/annotation-config/autowired-qualifiers.adoc[Fine-tuning Annotation-based Autowiring with Qualifiers].
+The `@Qualifier` annotation is discussed in
+xref:core/beans/annotation-config/autowired-qualifiers.adoc[Fine-tuning Annotation-based Autowiring with Qualifiers].
 The examples in that section demonstrate the use of the `@Qualifier` annotation and
 custom qualifier annotations to provide fine-grained control when you resolve autowire
 candidates. Because those examples were based on XML bean definitions, the qualifier

framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-autowire.adoc

@@ -60,6 +60,7 @@ instance's values consist of all bean instances that match the expected type, an
 `Map` instance's keys contain the corresponding bean names.
 
 
+
 [[beans-autowired-exceptions]]
 == Limitations and Disadvantages of Autowiring
 
@@ -101,10 +102,10 @@ In the latter scenario, you have several options:
 == 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 `<bean/>` element to `false`. The container
-makes that specific bean definition unavailable to the autowiring infrastructure
-(including annotation style configurations such as xref:core/beans/annotation-config/autowired.adoc[`@Autowired`]
-).
+the `autowire-candidate` attribute of the `<bean/>` element to `false`; with the `@Bean`
+annotation, the attribute is named `autowireCandidate`. The container makes that specific
+bean definition unavailable to the autowiring infrastructure, including annotation-based
+injection points such as xref:core/beans/annotation-config/autowired.adoc[`@Autowired`].
 
 NOTE: The `autowire-candidate` attribute is designed to only affect type-based autowiring.
 It does not affect explicit references by name, which get resolved even if the
@@ -119,8 +120,8 @@ provide multiple patterns, define them in a comma-separated list. An explicit va
 `true` or `false` for a bean definition's `autowire-candidate` attribute always takes
 precedence. For such beans, the pattern matching rules do not apply.
 
-These techniques are useful for beans that you never want to be injected into other
-beans by autowiring. It does not mean that an excluded bean cannot itself be configured by
+These techniques are useful for beans that you never want to be injected into other beans
+by autowiring. It does not mean that an excluded bean cannot itself be configured by
 using autowiring. Rather, the bean itself is not a candidate for autowiring other beans.
 
 

framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-dependson.adoc

@@ -4,12 +4,13 @@
 If a bean is a dependency of another bean, that usually means that one bean is set as a
 property of another. Typically you accomplish this with the
 xref:core/beans/dependencies/factory-properties-detailed.adoc#beans-ref-element[`<ref/>` element>]
-in XML-based configuration metadata. However, sometimes dependencies between beans are
-less direct. An example is when a static initializer in a class needs to be triggered,
-such as for database driver registration. The `depends-on` attribute can explicitly force
-one or more beans to be initialized before the bean using this element is initialized.
-The following example uses the `depends-on` attribute to express a dependency on a single
-bean:
+in XML-based metadata or through xref:core/beans/dependencies/factory-autowire.adoc[autowiring].
+
+However, sometimes dependencies between beans are less direct. An example is when a static
+initializer in a class needs to be triggered, such as for database driver registration.
+The `depends-on` attribute or `@DependsOn` annotation can explicitly force one or more beans
+to be initialized before the bean using this element is initialized. The following example
+uses the `depends-on` attribute to express a dependency on a single bean:
 
 [source,xml,indent=0,subs="verbatim,quotes"]
 ----
@@ -32,10 +33,10 @@ delimiters):
 ----
 
 NOTE: The `depends-on` attribute can specify both an initialization-time dependency and,
-in the case of xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singleton] beans only, a corresponding
-destruction-time dependency. Dependent beans that define a `depends-on` relationship
-with a given bean are destroyed first, prior to the given bean itself being destroyed.
-Thus, `depends-on` can also control shutdown order.
+in the case of xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singleton]
+beans only, a corresponding destruction-time dependency. Dependent beans that define a
+`depends-on` relationship with a given bean are destroyed first, prior to the given bean
+itself being destroyed. Thus, `depends-on` can also control shutdown order.