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] 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 25bbaff2b6..34511055f9 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 11bdc1e25a..bb5b6ef4aa 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]