Merge branch '5.1.x'
This commit is contained in:
@@ -4425,9 +4425,9 @@ implementation type, consider declaring the most specific return type on your fa
|
||||
method (at least as specific as required by the injection points referring to your bean).
|
||||
====
|
||||
|
||||
You can also provide all beans of a particular type from the
|
||||
`ApplicationContext` by adding the annotation to a field or method that expects an array
|
||||
of that type, as the following example shows:
|
||||
You can also provide all beans of a particular type from the `ApplicationContext`
|
||||
by adding the annotation to a field or method that expects an array of that type,
|
||||
as the following example shows:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
@@ -4477,8 +4477,8 @@ Note that the standard `javax.annotation.Priority` annotation is not available a
|
||||
through `@Order` values in combination with `@Primary` on a single bean for each type.
|
||||
====
|
||||
|
||||
Even typed `Map` instances can be autowired as long as the expected key type is `String`. The Map
|
||||
values contain all beans of the expected type, and the keys contain the
|
||||
Even typed `Map` instances can be autowired as long as the expected key type is `String`.
|
||||
The Map values contain all beans of the expected type, and the keys contain the
|
||||
corresponding bean names, as the following example shows:
|
||||
|
||||
[source,java,indent=0]
|
||||
@@ -4497,10 +4497,14 @@ corresponding bean names, as the following example shows:
|
||||
}
|
||||
----
|
||||
|
||||
By default, the autowiring fails whenever zero candidate beans are available. The
|
||||
default behavior is to treat annotated methods, constructors, and fields as
|
||||
indicating required dependencies. You can change this behavior as demonstrated, in the
|
||||
following example:
|
||||
By default, autowiring fails when no matching candidate beans are available for
|
||||
a given injection point. In the case of a declared array, collection or map,
|
||||
at least one matching element is expected.
|
||||
|
||||
The default behavior is to treat annotated methods and fields as indicating
|
||||
required dependencies. You can change this behavior as demonstrated in the
|
||||
following example, enabling the framework to skip a non-satisfiable injection
|
||||
point through marking it as non-required:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
@@ -4518,18 +4522,34 @@ following example:
|
||||
}
|
||||
----
|
||||
|
||||
A non-required method will not be called at all if its dependency (or one of its
|
||||
dependencies in case of multiple arguments) is not available. A non-required field
|
||||
will not get populated at all in such case, leaving its default value in place.
|
||||
|
||||
Injected constructor and factory method arguments are a special case since the
|
||||
'required' flag on `@Autowired` has a somewhat different meaning due to Spring's
|
||||
constructor resolution algorithm potentially dealing with multiple constructors.
|
||||
Constructor and factory method arguments are effectively required by default but
|
||||
with a few special rules in a single-constructor scenario, such as multi-element
|
||||
injection points (arrays, collections, maps) resolving to empty instances if no
|
||||
matching beans are available. This allows for a common implementation pattern
|
||||
where all dependencies can be declared in a unique multi-argument constructor,
|
||||
e.g. declared as a single public constructor without an `@Autowired` annotation.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Only one annotated constructor per-class can be marked as required, but multiple
|
||||
non-required constructors can be annotated. In that case, each is considered among the
|
||||
candidates and Spring uses the greediest constructor whose dependencies can be
|
||||
Only one annotated constructor per class can be marked as required, but multiple
|
||||
non-required constructors can be annotated. In that case, each is considered among
|
||||
the candidates and Spring uses the greediest constructor whose dependencies can be
|
||||
satisfied -- that is, the constructor that has the largest number of arguments.
|
||||
The constructor resolution algorithm is the same as for non-annotated classes with
|
||||
overloaded constructors, just narrowing the candidates to annotated constructors.
|
||||
|
||||
The required attribute of `@Autowired` is recommended over the `@Required` annotation.
|
||||
The required attribute indicates that the property is not required for autowiring
|
||||
purposes. The property is ignored if it cannot be autowired. `@Required`, on the other
|
||||
hand, is stronger in that it enforces the property that was set by any means supported
|
||||
by the container. If no value is injected, a corresponding exception is raised.
|
||||
The 'required' attribute of `@Autowired` is recommended over the `@Required` annotation
|
||||
on setter methods. The 'required' attribute indicates that the property is not required
|
||||
for autowiring purposes. The property is ignored if it cannot be autowired. `@Required`,
|
||||
on the other hand, is stronger in that it enforces the property to be set by any means
|
||||
supported by the container. If no value is defined, a corresponding exception is raised.
|
||||
====
|
||||
|
||||
Alternatively, you can express the non-required nature of a particular dependency
|
||||
|
||||
Reference in New Issue
Block a user