From 29fdcf56eb0d326720e4bc88e59e8bb080a3431c Mon Sep 17 00:00:00 2001 From: Sam Brannen <104798+sbrannen@users.noreply.github.com> Date: Thu, 29 Aug 2024 15:15:26 +0200 Subject: [PATCH 1/2] Polishing --- .../pages/core/beans/dependencies/factory-collaborators.adoc | 2 +- .../pages/core/beans/java/composing-configuration-classes.adoc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc b/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc index 25bbaff2b63..34511055f92 100644 --- a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc +++ b/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc @@ -162,7 +162,7 @@ Kotlin:: .[[beans-factory-ctor-arguments-type]]Constructor argument type matching -- In the preceding scenario, the container can use type matching with simple types if -you explicitly specify the type of the constructor argument by using the `type` attribute, +you explicitly specify the type of the constructor argument via the `type` attribute, as the following example shows: [source,xml,indent=0,subs="verbatim,quotes"] diff --git a/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc b/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc index 11bdc1e25a8..bb5b6ef4aa3 100644 --- a/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc +++ b/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc @@ -116,7 +116,7 @@ the configuration model, in that references to other beans must be valid Java sy Fortunately, solving this problem is simple. As xref:core/beans/java/bean-annotation.adoc#beans-java-dependencies[we already discussed], a `@Bean` method can have an arbitrary number of parameters that describe the bean -dependencies. Consider the following more real-world scenario with several `@Configuration` +dependencies. Consider the following more realistic scenario with several `@Configuration` classes, each depending on beans declared in the others: [tabs] From acf82e7c6dde2e1f722475d1a87defcb773bbc71 Mon Sep 17 00:00:00 2001 From: Sam Brannen <104798+sbrannen@users.noreply.github.com> Date: Thu, 29 Aug 2024 15:39:10 +0200 Subject: [PATCH 2/2] Use discrete headings instead of titled blocks in reference manual This code switches from titled blocks to discrete headings in order to properly format pseudo-section headers in the reference manual. Closes gh-33447 --- .../dependencies/factory-collaborators.adoc | 21 ++++++++++-------- .../java/composing-configuration-classes.adoc | 22 ++++++++++--------- 2 files changed, 24 insertions(+), 19 deletions(-) diff --git a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc b/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc index 34511055f92..4bc08e9bfa0 100644 --- a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc +++ b/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc @@ -159,8 +159,10 @@ Kotlin:: ---- ====== -.[[beans-factory-ctor-arguments-type]]Constructor argument type matching --- +[discrete] +[[beans-factory-ctor-arguments-type]] +==== Constructor argument type matching + In the preceding scenario, the container can use type matching with simple types if you explicitly specify the type of the constructor argument via the `type` attribute, as the following example shows: @@ -172,10 +174,11 @@ as the following example shows: ---- --- -.[[beans-factory-ctor-arguments-index]]Constructor argument index --- +[discrete] +[[beans-factory-ctor-arguments-index]] +==== Constructor argument index + You can use the `index` attribute to specify explicitly the index of constructor arguments, as the following example shows: @@ -191,10 +194,11 @@ In addition to resolving the ambiguity of multiple simple values, specifying an resolves ambiguity where a constructor has two arguments of the same type. NOTE: The index is 0-based. --- -.[[beans-factory-ctor-arguments-name]]Constructor argument name --- +[discrete] +[[beans-factory-ctor-arguments-name]] +==== Constructor argument name + You can also use the constructor parameter name for value disambiguation, as the following example shows: @@ -244,7 +248,6 @@ Kotlin:: constructor(val years: Int, val ultimateAnswer: String) ---- ====== --- [[beans-setter-injection]] diff --git a/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc b/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc index bb5b6ef4aa3..dab7103ab3a 100644 --- a/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc +++ b/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc @@ -331,8 +331,10 @@ TIP: Constructor injection in `@Configuration` classes is only supported as of S Framework 4.3. Note also that there is no need to specify `@Autowired` if the target bean defines only one constructor. -.[[beans-java-injecting-imported-beans-fq]]Fully-qualifying imported beans for ease of navigation --- +[discrete] +[[beans-java-injecting-imported-beans-fq]] +==== Fully-qualifying imported beans for ease of navigation + In the preceding scenario, using `@Autowired` works well and provides the desired modularity, but determining exactly where the autowired bean definitions are declared is still somewhat ambiguous. For example, as a developer looking at `ServiceConfig`, how do @@ -501,7 +503,6 @@ Now `ServiceConfig` is loosely coupled with respect to the concrete get a type hierarchy of `RepositoryConfig` implementations. In this way, navigating `@Configuration` classes and their dependencies becomes no different than the usual process of navigating interface-based code. --- TIP: If you want to influence the startup creation order of certain beans, consider declaring some of them as `@Lazy` (for creation on first access instead of on startup) @@ -594,8 +595,10 @@ that uses Spring XML, it is easier to create `@Configuration` classes on an as-needed basis and include them from the existing XML files. Later in this section, we cover the options for using `@Configuration` classes in this kind of "`XML-centric`" situation. -.[[beans-java-combining-xml-centric-declare-as-bean]]Declaring `@Configuration` classes as plain Spring `` elements --- +[discrete] +[[beans-java-combining-xml-centric-declare-as-bean]] +==== Declaring `@Configuration` classes as plain Spring `` elements + Remember that `@Configuration` classes are ultimately bean definitions in the container. In this series examples, we create a `@Configuration` class named `AppConfig` and include it within `system-test-config.xml` as a `` definition. Because @@ -703,16 +706,16 @@ Kotlin:: ---- ====== - NOTE: In `system-test-config.xml` file, the `AppConfig` `` does not declare an `id` element. While it would be acceptable to do so, it is unnecessary, given that no other bean ever refers to it, and it is unlikely to be explicitly fetched from the container by name. Similarly, the `DataSource` bean is only ever autowired by type, so an explicit bean `id` is not strictly required. --- -.[[beans-java-combining-xml-centric-component-scan]] Using to pick up `@Configuration` classes --- +[discrete] +[[beans-java-combining-xml-centric-component-scan]] +==== Using to pick up `@Configuration` classes + Because `@Configuration` is meta-annotated with `@Component`, `@Configuration`-annotated classes are automatically candidates for component scanning. Using the same scenario as described in the previous example, we can redefine `system-test-config.xml` to take advantage of component-scanning. @@ -736,7 +739,6 @@ The following example shows the modified `system-test-config.xml` file: ---- --- [[beans-java-combining-java-centric]] === `@Configuration` Class-centric Use of XML with `@ImportResource`