root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Polish core-beans.adoc

This commit is contained in:
Sam Brannen 2021-03-16 12:31:14 +01:00
parent 3ab39eda08
commit f7678cdcdd
1 changed files with 11 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
src/docs/asciidoc/core/core-beans.adoc
View File

@ -923,7 +923,7 @@ injection:
public class SimpleMovieLister { public class SimpleMovieLister {
// the SimpleMovieLister has a dependency on a MovieFinder // the SimpleMovieLister has a dependency on a MovieFinder
private MovieFinder movieFinder; private final MovieFinder movieFinder;
// a constructor so that the Spring container can inject a MovieFinder // a constructor so that the Spring container can inject a MovieFinder
public SimpleMovieLister(MovieFinder movieFinder) { public SimpleMovieLister(MovieFinder movieFinder) {
@ -943,7 +943,7 @@ injection:
---- ----
Notice that there is nothing special about this class. It is a POJO that Notice that there is nothing special about this class. It is a POJO that
has no dependencies on container specific interfaces, base classes or annotations. has no dependencies on container specific interfaces, base classes, or annotations.
[[beans-factory-ctor-arguments-resolution]] [[beans-factory-ctor-arguments-resolution]]
===== Constructor Argument Resolution ===== Constructor Argument Resolution
@ -974,10 +974,10 @@ being instantiated. Consider the following class:
class ThingOne(thingTwo: ThingTwo, thingThree: ThingThree) class ThingOne(thingTwo: ThingTwo, thingThree: ThingThree)
---- ----
Assuming that `ThingTwo` and `ThingThree` classes are not related by inheritance, no potential Assuming that the `ThingTwo` and `ThingThree` classes are not related by inheritance, no
ambiguity exists. Thus, the following configuration works fine, and you do not need to specify potential ambiguity exists. Thus, the following configuration works fine, and you do not
the constructor argument indexes or types explicitly in the `<constructor-arg/>` need to specify the constructor argument indexes or types explicitly in the
element. `<constructor-arg/>` element.
[source,xml,indent=0,subs="verbatim,quotes"] [source,xml,indent=0,subs="verbatim,quotes"]
---- ----
@ -1006,10 +1006,10 @@ by type without help. Consider the following class:
public class ExampleBean { public class ExampleBean {
// Number of years to calculate the Ultimate Answer // Number of years to calculate the Ultimate Answer
private int years; private final int years;
// The Answer to Life, the Universe, and Everything // The Answer to Life, the Universe, and Everything
private String ultimateAnswer; private final String ultimateAnswer;
public ExampleBean(int years, String ultimateAnswer) { public ExampleBean(int years, String ultimateAnswer) {
this.years = years; this.years = years;
@ -1031,7 +1031,7 @@ by type without help. Consider the following class:
.[[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 by using 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"]
@ -1251,7 +1251,8 @@ visibility of some configuration issues is why `ApplicationContext` implementati
default pre-instantiate singleton beans. At the cost of some upfront time and memory to default pre-instantiate singleton beans. At the cost of some upfront time and memory to
create these beans before they are actually needed, you discover configuration issues create these beans before they are actually needed, you discover configuration issues
when the `ApplicationContext` is created, not later. You can still override this default when the `ApplicationContext` is created, not later. You can still override this default
behavior so that singleton beans initialize lazily, rather than being pre-instantiated. behavior so that singleton beans initialize lazily, rather than being eagerly
pre-instantiated.
If no circular dependencies exist, when one or more collaborating beans are being If no circular dependencies exist, when one or more collaborating beans are being
injected into a dependent bean, each collaborating bean is totally configured prior injected into a dependent bean, each collaborating bean is totally configured prior