2
2
= The IoC container
3
3
4
4
5
+
6
+
5
7
[[beans-introduction]]
6
8
== Introduction to the Spring IoC container and beans
7
9
@@ -400,6 +402,7 @@ a dependency on a specific bean through metadata (e.g. an autowiring annotation)
400
402
401
403
[[beans-definition]]
402
404
== Bean overview
405
+
403
406
A Spring IoC container manages one or more __beans__. These beans are created with the
404
407
configuration metadata that you supply to the container, for example, in the form of XML
405
408
`<bean/>` definitions.
@@ -778,6 +781,7 @@ Spring container that will create objects through an
778
781
779
782
[[beans-dependencies]]
780
783
== Dependencies
784
+
781
785
A typical enterprise application does not consist of a single object (or bean in the
782
786
Spring parlance). Even the simplest application has a few objects that work together to
783
787
present what the end-user sees as a coherent application. This next section explains how
@@ -2380,6 +2384,7 @@ shortest string that will match an argument type.
2380
2384
2381
2385
[[beans-factory-scopes]]
2382
2386
== Bean scopes
2387
+
2383
2388
When you create a bean definition, you create a __recipe__ for creating actual instances
2384
2389
of the class defined by that bean definition. The idea that a bean definition is a
2385
2390
recipe is important, because it means that, as with a class, you can create many object
@@ -3602,6 +3607,7 @@ beans that require programmatic access to the container.
3602
3607
3603
3608
[[beans-child-bean-definitions]]
3604
3609
== Bean definition inheritance
3610
+
3605
3611
A bean definition can contain a lot of configuration information, including constructor
3606
3612
arguments, property values, and container-specific information such as initialization
3607
3613
method, static factory method name, and so on. A child bean definition inherits
@@ -3687,6 +3693,7 @@ context will actually (attempt to) pre-instantiate the `abstract` bean.
3687
3693
3688
3694
[[beans-factory-extension]]
3689
3695
== Container Extension Points
3696
+
3690
3697
Typically, an application developer does not need to subclass `ApplicationContext`
3691
3698
implementation classes. Instead, the Spring IoC container can be extended by plugging in
3692
3699
implementations of special integration interfaces. The next few sections describe these
@@ -5173,6 +5180,7 @@ For details about the effects of combining various lifecycle mechanisms, see
5173
5180
5174
5181
[[beans-classpath-scanning]]
5175
5182
== Classpath scanning and managed components
5183
+
5176
5184
Most examples in this chapter use XML to specify the configuration metadata that produces
5177
5185
each `BeanDefinition` within the Spring container. The previous section
5178
5186
(<<beans-annotation-config>>) demonstrates how to provide a lot of the configuration
@@ -5299,6 +5307,7 @@ https://github.com/spring-projects/spring-framework/wiki/Spring-Annotation-Progr
5299
5307
wiki page.
5300
5308
5301
5309
5310
+
5302
5311
[[beans-scanning-autodetection]]
5303
5312
=== Automatically detecting classes and registering bean definitions
5304
5313
@@ -5839,6 +5848,7 @@ metadata is provided per-instance rather than per-class.
5839
5848
5840
5849
[[beans-scanning-index]]
5841
5850
=== Generating an index of candidate components
5851
+
5842
5852
While classpath scanning is very fast, it is possible to improve the startup performance
5843
5853
of large applications by creating a static list of candidates at compilation time. In this
5844
5854
mode, _all modules_ of the application must use this mechanism as, when the
@@ -5893,8 +5903,10 @@ classpath.
5893
5903
5894
5904
5895
5905
5906
+
5896
5907
[[beans-standard-annotations]]
5897
5908
== Using JSR 330 Standard Annotations
5909
+
5898
5910
Starting with Spring 3.0, Spring offers support for JSR-330 standard annotations
5899
5911
(Dependency Injection). Those annotations are scanned in the same way as the Spring
5900
5912
annotations. You just need to have the relevant jars in your classpath.
@@ -6742,6 +6754,7 @@ annotation can be used:
6742
6754
----
6743
6755
6744
6756
6757
+
6745
6758
[[beans-java-configuration-annotation]]
6746
6759
=== Using the @Configuration annotation
6747
6760
@@ -7979,7 +7992,7 @@ AspectJ load-time weaving, see <<aop-aj-ltw>>.
7979
7992
7980
7993
7981
7994
[[context-introduction]]
7982
- == Additional Capabilities of the ApplicationContext
7995
+ == Additional capabilities of the ApplicationContext
7983
7996
7984
7997
As was discussed in the chapter introduction, the `org.springframework.beans.factory`
7985
7998
package provides basic functionality for managing and manipulating beans, including in a
@@ -8211,7 +8224,7 @@ out the `ReloadableResourceBundleMessageSource` javadocs for details.
8211
8224
8212
8225
8213
8226
[[context-functionality-events]]
8214
- === Standard and Custom Events
8227
+ === Standard and custom events
8215
8228
8216
8229
Event handling in the `ApplicationContext` is provided through the `ApplicationEvent`
8217
8230
class and `ApplicationListener` interface. If a bean that implements the
@@ -8400,8 +8413,9 @@ http://www.enterpriseintegrationpatterns.com[pattern-oriented], event-driven
8400
8413
architectures that build upon the well-known Spring programming model.
8401
8414
====
8402
8415
8416
+
8403
8417
[[context-functionality-events-annotation]]
8404
- ==== Annotation-based Event Listeners
8418
+ ==== Annotation-based event listeners
8405
8419
8406
8420
As of Spring 4.2, an event listener can be registered on any public method of a managed
8407
8421
bean via the `EventListener` annotation. The `BlackListNotifier` can be rewritten as
@@ -8508,6 +8522,7 @@ This new method will publish a new `ListUpdateEvent` for every `BlackListEvent`
8508
8522
by the method above. If you need to publish several events, just return a `Collection` of
8509
8523
events instead.
8510
8524
8525
+
8511
8526
[[context-functionality-events-async]]
8512
8527
==== Asynchronous Listeners
8513
8528
@@ -8534,7 +8549,7 @@ Be aware of the following limitations when using asynchronous events:
8534
8549
8535
8550
8536
8551
[[context-functionality-events-order]]
8537
- ==== Ordering Listeners
8552
+ ==== Ordering listeners
8538
8553
8539
8554
If you need the listener to be invoked before another one, just add the `@Order`
8540
8555
annotation to the method declaration:
@@ -8549,8 +8564,9 @@ annotation to the method declaration:
8549
8564
}
8550
8565
----
8551
8566
8567
+
8552
8568
[[context-functionality-events-generics]]
8553
- ==== Generic Events
8569
+ ==== Generic events
8554
8570
8555
8571
You may also use generics to further define the structure of your event. Consider an
8556
8572
`EntityCreatedEvent<T>` where `T` is the type of the actual entity that got created. You
@@ -8716,14 +8732,15 @@ be used by other application modules on the same machine.
8716
8732
8717
8733
[[beans-beanfactory]]
8718
8734
== The BeanFactory
8735
+
8719
8736
The `BeanFactory` provides the underlying basis for Spring's IoC functionality but it is
8720
8737
only used directly in integration with other third-party frameworks and is now largely
8721
8738
historical in nature for most users of Spring. The `BeanFactory` and related interfaces,
8722
8739
such as `BeanFactoryAware`, `InitializingBean`, `DisposableBean`, are still present in
8723
8740
Spring for the purposes of backward compatibility with the large number of third-party
8724
8741
frameworks that integrate with Spring. Often third-party components that can not use
8725
- more modern equivalents such as `@PostConstruct` or `@PreDestroy` in order to remain
8726
- compatible with JDK 1.4 or to avoid a dependency on JSR-250.
8742
+ more modern equivalents such as `@PostConstruct` or `@PreDestroy` in order to avoid a
8743
+ dependency on JSR-250.
8727
8744
8728
8745
This section provides additional background into the differences between the
8729
8746
`BeanFactory` and `ApplicationContext` and how one might access the IoC container
0 commit comments