@ -4425,9 +4425,9 @@ implementation type, consider declaring the most specific return type on your fa
@@ -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
@@ -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:
@@ -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:
@@ -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 perclass 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 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 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
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
Juergen Hoeller
6 years ago