Polishing
This commit is contained in:
parent
186deb777f
commit
29fdcf56eb
|
@ -162,7 +162,7 @@ Kotlin::
|
||||||
.[[beans-factory-ctor-arguments-type]]Constructor argument type matching
|
.[[beans-factory-ctor-arguments-type]]Constructor argument type matching
|
||||||
--
|
--
|
||||||
In the preceding scenario, the container can use type matching with simple types if
|
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:
|
as the following example shows:
|
||||||
|
|
||||||
[source,xml,indent=0,subs="verbatim,quotes"]
|
[source,xml,indent=0,subs="verbatim,quotes"]
|
||||||
|
|
|
@ -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
|
Fortunately, solving this problem is simple. As
|
||||||
xref:core/beans/java/bean-annotation.adoc#beans-java-dependencies[we already discussed],
|
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
|
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:
|
classes, each depending on beans declared in the others:
|
||||||
|
|
||||||
[tabs]
|
[tabs]
|
||||||
|
|
Loading…
Reference in New Issue