|
|
|
@ -524,15 +524,13 @@ container that hosts the bean. A bean usually has only one identifier. However, |
|
|
|
requires more than one, the extra ones can be considered aliases. |
|
|
|
requires more than one, the extra ones can be considered aliases. |
|
|
|
|
|
|
|
|
|
|
|
In XML-based configuration metadata, you use the `id` attribute, the `name` attribute, or |
|
|
|
In XML-based configuration metadata, you use the `id` attribute, the `name` attribute, or |
|
|
|
both to specify the bean identifiers. The `id` attribute lets you specify |
|
|
|
both to specify bean identifiers. The `id` attribute lets you specify exactly one `id`. |
|
|
|
exactly one id. Conventionally, these names are alphanumeric ('myBean', |
|
|
|
Conventionally, these names are alphanumeric ('myBean', 'someService', etc.), but they |
|
|
|
'someService', etc.), but they can contain special characters as well. If you want to |
|
|
|
can contain special characters as well. If you want to introduce other aliases for the |
|
|
|
introduce other aliases for the bean, you can also specify them in the `name` |
|
|
|
bean, you can also specify them in the `name` attribute, separated by a comma (`,`), |
|
|
|
attribute, separated by a comma (`,`), semicolon (`;`), or white space. As a |
|
|
|
semicolon (`;`), or white space. Although the `id` attribute is defined as an |
|
|
|
historical note, in versions prior to Spring 3.1, the `id` attribute was |
|
|
|
`xsd:string` type, bean `id` uniqueness is enforced by the container, though not by XML |
|
|
|
defined as an `xsd:ID` type, which constrained possible characters. As of 3.1, |
|
|
|
parsers. |
|
|
|
it is defined as an `xsd:string` type. Note that bean `id` uniqueness is still |
|
|
|
|
|
|
|
enforced by the container, though no longer by XML parsers. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You are not required to supply a `name` or an `id` for a bean. If you do not supply a |
|
|
|
You are not required to supply a `name` or an `id` for a bean. If you do not supply a |
|
|
|
`name` or `id` explicitly, the container generates a unique name for that bean. However, |
|
|
|
`name` or `id` explicitly, the container generates a unique name for that bean. However, |
|
|
|
@ -2704,8 +2702,8 @@ The following table describes the supported scopes: |
|
|
|
the context of a web-aware Spring `ApplicationContext`. |
|
|
|
the context of a web-aware Spring `ApplicationContext`. |
|
|
|
|=== |
|
|
|
|=== |
|
|
|
|
|
|
|
|
|
|
|
NOTE: As of Spring 3.0, a thread scope is available but is not registered by default. For |
|
|
|
NOTE: A thread scope is available but is not registered by default. For more information, |
|
|
|
more information, see the documentation for |
|
|
|
see the documentation for |
|
|
|
{api-spring-framework}/context/support/SimpleThreadScope.html[`SimpleThreadScope`]. |
|
|
|
{api-spring-framework}/context/support/SimpleThreadScope.html[`SimpleThreadScope`]. |
|
|
|
For instructions on how to register this or any other custom scope, see |
|
|
|
For instructions on how to register this or any other custom scope, see |
|
|
|
<<beans-factory-scopes-custom-using>>. |
|
|
|
<<beans-factory-scopes-custom-using>>. |
|
|
|
@ -4590,26 +4588,24 @@ configuration becomes decentralized and harder to control. |
|
|
|
|
|
|
|
|
|
|
|
No matter the choice, Spring can accommodate both styles and even mix them together. |
|
|
|
No matter the choice, Spring can accommodate both styles and even mix them together. |
|
|
|
It is worth pointing out that through its <<beans-java, JavaConfig>> option, Spring lets |
|
|
|
It is worth pointing out that through its <<beans-java, JavaConfig>> option, Spring lets |
|
|
|
annotations be used in a non-invasive way, without touching the target components |
|
|
|
annotations be used in a non-invasive way, without touching the target components' |
|
|
|
source code and that, in terms of tooling, all configuration styles are supported by the |
|
|
|
source code and that, in terms of tooling, all configuration styles are supported by |
|
|
|
https://spring.io/tools[Spring Tools for Eclipse]. |
|
|
|
https://spring.io/tools[Spring Tools] for Eclipse, Visual Studio Code, and Theia. |
|
|
|
**** |
|
|
|
**** |
|
|
|
|
|
|
|
|
|
|
|
An alternative to XML setup is provided by annotation-based configuration, which relies |
|
|
|
An alternative to XML setup is provided by annotation-based configuration, which relies |
|
|
|
on the bytecode metadata for wiring up components instead of angle-bracket declarations. |
|
|
|
on bytecode metadata for wiring up components instead of XML declarations. Instead of |
|
|
|
Instead of using XML to describe a bean wiring, the developer moves the configuration |
|
|
|
using XML to describe a bean wiring, the developer moves the configuration into the |
|
|
|
into the component class itself by using annotations on the relevant class, method, or |
|
|
|
component class itself by using annotations on the relevant class, method, or field |
|
|
|
field declaration. As mentioned in <<beans-factory-extension-bpp-examples-aabpp>>, using |
|
|
|
declaration. As mentioned in <<beans-factory-extension-bpp-examples-aabpp>>, using a |
|
|
|
a `BeanPostProcessor` in conjunction with annotations is a common means of extending the |
|
|
|
`BeanPostProcessor` in conjunction with annotations is a common means of extending the |
|
|
|
Spring IoC container. For example, Spring 2.5 introduced an annotation-based approach to |
|
|
|
Spring IoC container. For example, the <<beans-autowired-annotation, `@Autowired`>> |
|
|
|
drive Spring's dependency injection. Essentially, the <<beans-autowired-annotation, |
|
|
|
annotation provides the same capabilities as described in <<beans-factory-autowire>> but |
|
|
|
`@Autowired`>> annotation provides the same capabilities as described in |
|
|
|
with more fine-grained control and wider applicability. In addition, Spring provides |
|
|
|
<<beans-factory-autowire>> but with more fine-grained control and wider applicability. |
|
|
|
support for JSR-250 annotations, such as `@PostConstruct` and `@PreDestroy`, as well as |
|
|
|
Spring 2.5 also added support for JSR-250 annotations, such as `@PostConstruct` and |
|
|
|
support for JSR-330 (Dependency Injection for Java) annotations contained in the |
|
|
|
`@PreDestroy`. Spring 3.0 added support for JSR-330 (Dependency Injection for Java) |
|
|
|
`jakarta.inject` package such as `@Inject` and `@Named`. Details about those annotations |
|
|
|
annotations contained in the `jakarta.inject` package such as `@Inject` and `@Named`. |
|
|
|
can be found in the <<beans-standard-annotations, relevant section>>. |
|
|
|
Details about those annotations can be found in the <<beans-standard-annotations, |
|
|
|
|
|
|
|
relevant section>>. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[NOTE] |
|
|
|
[NOTE] |
|
|
|
==== |
|
|
|
==== |
|
|
|
@ -6237,7 +6233,7 @@ simply to be added to the application's classpath like any other library. |
|
|
|
Most examples in this chapter use XML to specify the configuration metadata that produces |
|
|
|
Most examples in this chapter use XML to specify the configuration metadata that produces |
|
|
|
each `BeanDefinition` within the Spring container. The previous section |
|
|
|
each `BeanDefinition` within the Spring container. The previous section |
|
|
|
(<<beans-annotation-config>>) demonstrates how to provide a lot of the configuration |
|
|
|
(<<beans-annotation-config>>) demonstrates how to provide a lot of the configuration |
|
|
|
metadata through source-level annotations. Even in those examples, however, the "`base`" |
|
|
|
metadata through source-level annotations. Even in those examples, however, the "base" |
|
|
|
bean definitions are explicitly defined in the XML file, while the annotations drive only |
|
|
|
bean definitions are explicitly defined in the XML file, while the annotations drive only |
|
|
|
the dependency injection. This section describes an option for implicitly detecting the |
|
|
|
the dependency injection. This section describes an option for implicitly detecting the |
|
|
|
candidate components by scanning the classpath. Candidate components are classes that |
|
|
|
candidate components by scanning the classpath. Candidate components are classes that |
|
|
|
@ -6249,10 +6245,9 @@ the container. |
|
|
|
|
|
|
|
|
|
|
|
[NOTE] |
|
|
|
[NOTE] |
|
|
|
==== |
|
|
|
==== |
|
|
|
Starting with Spring 3.0, many features provided by the Spring JavaConfig project are |
|
|
|
You can define beans using Java rather than using XML files. Take a look at the |
|
|
|
part of the core Spring Framework. This allows you to define beans using Java rather |
|
|
|
`@Configuration`, `@Bean`, `@Import`, and `@DependsOn` annotations for examples of how to |
|
|
|
than using the traditional XML files. Take a look at the `@Configuration`, `@Bean`, |
|
|
|
use these features. |
|
|
|
`@Import`, and `@DependsOn` annotations for examples of how to use these new features. |
|
|
|
|
|
|
|
==== |
|
|
|
==== |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ -7172,9 +7167,9 @@ arrangement (as though no index were present at all) by setting `spring.index.ig |
|
|
|
[[beans-standard-annotations]] |
|
|
|
[[beans-standard-annotations]] |
|
|
|
== Using JSR 330 Standard Annotations |
|
|
|
== Using JSR 330 Standard Annotations |
|
|
|
|
|
|
|
|
|
|
|
Starting with Spring 3.0, Spring offers support for JSR-330 standard annotations |
|
|
|
Spring offers support for JSR-330 standard annotations (Dependency Injection). Those |
|
|
|
(Dependency Injection). Those annotations are scanned in the same way as the Spring |
|
|
|
annotations are scanned in the same way as the Spring annotations. To use them, you need |
|
|
|
annotations. To use them, you need to have the relevant jars in your classpath. |
|
|
|
to have the relevant jars in your classpath. |
|
|
|
|
|
|
|
|
|
|
|
[NOTE] |
|
|
|
[NOTE] |
|
|
|
===== |
|
|
|
===== |
|
|
|
@ -8611,22 +8606,24 @@ about singletons here. |
|
|
|
|
|
|
|
|
|
|
|
[NOTE] |
|
|
|
[NOTE] |
|
|
|
==== |
|
|
|
==== |
|
|
|
As of Spring 3.2, it is no longer necessary to add CGLIB to your classpath because CGLIB |
|
|
|
It is not necessary to add CGLIB to your classpath because CGLIB classes are repackaged |
|
|
|
classes have been repackaged under `org.springframework.cglib` and included directly |
|
|
|
under the `org.springframework.cglib` package and included directly within the |
|
|
|
within the spring-core JAR. |
|
|
|
`spring-core` JAR. |
|
|
|
==== |
|
|
|
==== |
|
|
|
|
|
|
|
|
|
|
|
[TIP] |
|
|
|
[TIP] |
|
|
|
==== |
|
|
|
==== |
|
|
|
There are a few restrictions due to the fact that CGLIB dynamically adds features at |
|
|
|
There are a few restrictions due to the fact that CGLIB dynamically adds features at |
|
|
|
startup-time. In particular, configuration classes must not be final. However, as |
|
|
|
startup-time. In particular, configuration classes must not be final. However, any |
|
|
|
of 4.3, any constructors are allowed on configuration classes, including the use of |
|
|
|
constructors are allowed on configuration classes, including the use of `@Autowired` or a |
|
|
|
`@Autowired` or a single non-default constructor declaration for default injection. |
|
|
|
single non-default constructor declaration for default injection. |
|
|
|
|
|
|
|
|
|
|
|
If you prefer to avoid any CGLIB-imposed limitations, consider declaring your `@Bean` |
|
|
|
If you prefer to avoid any CGLIB-imposed limitations, consider declaring your `@Bean` |
|
|
|
methods on non-`@Configuration` classes (for example, on plain `@Component` classes instead). |
|
|
|
methods on non-`@Configuration` classes (for example, on plain `@Component` classes |
|
|
|
Cross-method calls between `@Bean` methods are not then intercepted, so you have |
|
|
|
instead) or by annotating your configuration class with |
|
|
|
to exclusively rely on dependency injection at the constructor or method level there. |
|
|
|
`@Configuration(proxyBeanMethods = false)`. Cross-method calls between `@Bean` methods |
|
|
|
|
|
|
|
are then not intercepted, so you have to exclusively rely on dependency injection at the |
|
|
|
|
|
|
|
constructor or method level there. |
|
|
|
==== |
|
|
|
==== |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|