From 2622db1dbe58e2265036ae8b69db11c9bb437e87 Mon Sep 17 00:00:00 2001 From: Juergen Hoeller Date: Tue, 8 Oct 2024 11:26:42 +0200 Subject: [PATCH] Consistent references to annotation-based autowiring --- .../pages/core/beans/classpath-scanning.adoc | 9 ++++---- .../beans/dependencies/factory-autowire.adoc | 13 ++++++------ .../beans/dependencies/factory-dependson.adoc | 21 ++++++++++--------- 3 files changed, 23 insertions(+), 20 deletions(-) diff --git a/framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc b/framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc index 85d354a82c..8c067fed4f 100644 --- a/framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc +++ b/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 diff --git a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-autowire.adoc b/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-autowire.adoc index 829fe815a8..36d9a97502 100644 --- a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-autowire.adoc +++ b/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 `` 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 `` 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. diff --git a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-dependson.adoc b/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-dependson.adoc index bbc4c0ef20..9a076d3d56 100644 --- a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-dependson.adoc +++ b/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[`` 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.