|
1 | 1 | [[beans-classpath-scanning]] |
2 | 2 | = Classpath Scanning and Managed Components |
3 | 3 |
|
4 | | -Most examples in this chapter use XML to specify the configuration metadata that produces |
5 | | -each `BeanDefinition` within the Spring container. The previous section |
6 | | -(xref:core/beans/annotation-config.adoc[Annotation-based Container Configuration]) demonstrates how to provide a lot of the configuration |
7 | | -metadata through source-level annotations. Even in those examples, however, the "base" |
8 | | -bean definitions are explicitly defined in the XML file, while the annotations drive only |
9 | | -the dependency injection. This section describes an option for implicitly detecting the |
10 | | -candidate components by scanning the classpath. Candidate components are classes that |
11 | | -match against a filter criteria and have a corresponding bean definition registered with |
12 | | -the container. This removes the need to use XML to perform bean registration. Instead, you |
13 | | -can use annotations (for example, `@Component`), AspectJ type expressions, or your own |
| 4 | +Most examples in this chapter use XML to specify the configuration metadata that |
| 5 | +produces each `BeanDefinition` within the Spring container. The previous section |
| 6 | +(xref:core/beans/annotation-config.adoc[Annotation-based Container Configuration]) |
| 7 | +demonstrates how to provide a lot of the configuration metadata through source-level |
| 8 | +annotations. Even in those examples, however, the "base" bean definitions are explicitly |
| 9 | +defined in the XML file, while the annotations drive only the dependency injection. |
| 10 | + |
| 11 | +This section describes an option for implicitly detecting the candidate components by |
| 12 | +scanning the classpath. Candidate components are classes that match against a filter |
| 13 | +criteria and have a corresponding bean definition registered with the container. |
| 14 | +This removes the need to use XML to perform bean registration. Instead, you can use |
| 15 | +annotations (for example, `@Component`), AspectJ type expressions, or your own |
14 | 16 | custom filter criteria to select which classes have bean definitions registered with |
15 | 17 | the container. |
16 | 18 |
|
17 | 19 | [NOTE] |
18 | 20 | ==== |
19 | 21 | You can define beans using Java rather than using XML files. Take a look at the |
20 | | -`@Configuration`, `@Bean`, `@Import`, and `@DependsOn` annotations for examples of how to |
21 | | -use these features. |
| 22 | +`@Configuration`, `@Bean`, `@Import`, and `@DependsOn` annotations for examples |
| 23 | +of how to use these features. |
22 | 24 | ==== |
23 | 25 |
|
24 | 26 |
|
@@ -828,10 +830,10 @@ definitions, there is no notion of bean definition inheritance, and inheritance |
828 | 830 | hierarchies at the class level are irrelevant for metadata purposes. |
829 | 831 |
|
830 | 832 | For details on web-specific scopes such as "`request`" or "`session`" in a Spring context, |
831 | | -see xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other[Request, Session, Application, and WebSocket Scopes]. As with the pre-built annotations for those scopes, |
832 | | -you may also compose your own scoping annotations by using Spring's meta-annotation |
833 | | -approach: for example, a custom annotation meta-annotated with `@Scope("prototype")`, |
834 | | -possibly also declaring a custom scoped-proxy mode. |
| 833 | +see xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other[Request, Session, Application, and WebSocket Scopes]. |
| 834 | +As with the pre-built annotations for those scopes, you may also compose your own scoping |
| 835 | +annotations by using Spring's meta-annotation approach: for example, a custom annotation |
| 836 | +meta-annotated with `@Scope("prototype")`, possibly also declaring a custom scoped-proxy mode. |
835 | 837 |
|
836 | 838 | NOTE: To provide a custom strategy for scope resolution rather than relying on the |
837 | 839 | annotation-based approach, you can implement the |
@@ -873,7 +875,8 @@ Kotlin:: |
873 | 875 | ---- |
874 | 876 |
|
875 | 877 | When using certain non-singleton scopes, it may be necessary to generate proxies for the |
876 | | -scoped objects. The reasoning is described in xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other-injection[Scoped Beans as Dependencies]. |
| 878 | +scoped objects. The reasoning is described in |
| 879 | +xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other-injection[Scoped Beans as Dependencies]. |
877 | 880 | For this purpose, a scoped-proxy attribute is available on the component-scan |
878 | 881 | element. The three possible values are: `no`, `interfaces`, and `targetClass`. For example, |
879 | 882 | the following configuration results in standard JDK dynamic proxies: |
|
0 commit comments