Browse Source

Polishing

pull/33720/head
Sam Brannen 1 year ago
parent
commit
29fdcf56eb
  1. 2
      framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc
  2. 2
      framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc

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

@ -162,7 +162,7 @@ Kotlin:: @@ -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"]

2
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 @@ -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]

Loading…
Cancel
Save