@@ -1241,7 +1241,7 @@ The following example shows the data access objects `daos.xml` file:
1241
1241
<!-- additional collaborators and configuration for this bean go here -->
1242
1242
</bean>
1243
1243
1244
- <bean id="itemDao" class="org.springframework.samples.jpetstore.dao.jpa.JapItemDao ">
1244
+ <bean id="itemDao" class="org.springframework.samples.jpetstore.dao.jpa.JpaItemDao ">
1245
1245
<!-- additional collaborators and configuration for this bean go here -->
1246
1246
</bean>
1247
1247
@@ -1282,7 +1282,7 @@ to load bean definitions from another file or files. For example:
1282
1282
</beans>
1283
1283
----
1284
1284
1285
- In the preceding example, external bean definitions are loaded from three files,
1285
+ In the preceding example, external bean definitions are loaded from three files:
1286
1286
`services.xml`, `messageSource.xml`, and `themeSource.xml`. All location paths are
1287
1287
relative to the definition file doing the importing, so `services.xml` must be in the
1288
1288
same directory or classpath location as the file doing the importing, while
@@ -1511,7 +1511,7 @@ You use the `Class` property in one of two ways:
1511
1511
equivalent to Java code using the `new` operator.
1512
1512
* To specify the actual class containing the `static` factory method that will be
1513
1513
invoked to create the object, in the less common case where the container invokes a
1514
- `static`, __factory__ method on a class to create the bean. The object type returned
1514
+ `static` __factory__ method on a class to create the bean. The object type returned
1515
1515
from the invocation of the `static` factory method may be the same class or another
1516
1516
class entirely.
1517
1517
@@ -2046,12 +2046,12 @@ part of a Spring XML configuration file specifies some bean definitions:
2046
2046
[subs="verbatim,quotes"]
2047
2047
----
2048
2048
<bean id="exampleBean" class="examples.ExampleBean">
2049
- <!-- setter injection using the nested < ref/> element -->
2049
+ <!-- setter injection using the nested ref element -->
2050
2050
<property name="beanOne">
2051
2051
<ref bean="anotherExampleBean"/>
2052
2052
</property>
2053
2053
2054
- <!-- setter injection using the neater ' ref' attribute -->
2054
+ <!-- setter injection using the neater ref attribute -->
2055
2055
<property name="beanTwo" ref="yetAnotherBean"/>
2056
2056
<property name="integerProperty" value="1"/>
2057
2057
</bean>
@@ -2091,12 +2091,12 @@ in the XML file. The following example uses constructor-based DI:
2091
2091
[subs="verbatim,quotes"]
2092
2092
----
2093
2093
<bean id="exampleBean" class="examples.ExampleBean">
2094
- <!-- constructor injection using the nested < ref/> element -->
2094
+ <!-- constructor injection using the nested ref element -->
2095
2095
<constructor-arg>
2096
2096
<ref bean="anotherExampleBean"/>
2097
2097
</constructor-arg>
2098
2098
2099
- <!-- constructor injection using the neater ' ref' attribute -->
2099
+ <!-- constructor injection using the neater ref attribute -->
2100
2100
<constructor-arg ref="yetAnotherBean"/>
2101
2101
2102
2102
<constructor-arg type="int" value="1"/>
@@ -2297,18 +2297,12 @@ likely fatal results) when the `client` bean is actually instantiated. If the `c
2297
2297
bean is a <<beans-factory-scopes,prototype>> bean, this typo and the resulting exception
2298
2298
may only be discovered long after the container is deployed.
2299
2299
2300
- Additionally, if the referenced bean is in the same XML unit, and the bean name is the
2301
- bean __id__, you can use the `local` attribute, which allows the XML parser itself to
2302
- validate the bean id earlier, at XML document parse time.
2303
-
2304
- [source,xml,indent=0]
2305
- [subs="verbatim,quotes"]
2306
- ----
2307
- <property name="targetName">
2308
- <!-- a bean with id theTargetBean must exist; otherwise an exception will be thrown -->
2309
- <idref bean="theTargetBean"/>
2310
- </property>
2311
- ----
2300
+ [NOTE]
2301
+ ====
2302
+ The `local` attribute on the `idref` element is no longer supported in the 4.0 beans xsd
2303
+ since it does not provide value over a regular `bean` reference anymore. Simply change
2304
+ your existing `idref local` references to `idref bean` when upgrading to the 4.0 schema.
2305
+ ====
2312
2306
2313
2307
A common place (at least in versions earlier than Spring 2.0) where the `<idref/>` element
2314
2308
brings value is in the configuration of <<aop-pfb-1,AOP interceptors>> in a
@@ -2360,7 +2354,7 @@ container with a proxy that will have the same name as the parent bean.
2360
2354
[subs="verbatim,quotes"]
2361
2355
----
2362
2356
<!-- in the child (descendant) context -->
2363
- <bean id="accountService" <-- bean name is the same as the parent bean -->
2357
+ <bean id="accountService" <! -- bean name is the same as the parent bean -->
2364
2358
class="org.springframework.aop.framework.ProxyFactoryBean">
2365
2359
<property name="target">
2366
2360
<ref parent="accountService"/> <!-- notice how we refer to the parent bean -->
@@ -2586,7 +2580,14 @@ following XML-based configuration metadata snippet sets the email property to th
2586
2580
----
2587
2581
2588
2582
The preceding example is equivalent to the following Java code:
2589
- `exampleBean.setEmail("")`. The `<null/>` element handles `null` values. For example:
2583
+
2584
+ [source,java,indent=0]
2585
+ [subs="verbatim,quotes"]
2586
+ ----
2587
+ exampleBean.setEmail("")
2588
+ ----
2589
+
2590
+ The `<null/>` element handles `null` values. For example:
2590
2591
2591
2592
[source,xml,indent=0]
2592
2593
[subs="verbatim,quotes"]
@@ -2599,7 +2600,12 @@ The preceding example is equivalent to the following Java code:
2599
2600
----
2600
2601
2601
2602
The above configuration is equivalent to the following Java code:
2602
- `exampleBean.setEmail(null)`.
2603
+
2604
+ [source,java,indent=0]
2605
+ [subs="verbatim,quotes"]
2606
+ ----
2607
+ exampleBean.setEmail(null)
2608
+ ----
2603
2609
2604
2610
2605
2611
[[beans-p-namespace]]
@@ -3779,7 +3785,7 @@ of the scope. You can also do the `Scope` registration declaratively, using the
3779
3785
3780
3786
[NOTE]
3781
3787
====
3782
- When you place <aop:scoped-proxy/> in a `FactoryBean` implementation, it is the factory
3788
+ When you place ` <aop:scoped-proxy/>` in a `FactoryBean` implementation, it is the factory
3783
3789
bean itself that is scoped, not the object returned from `getObject()`.
3784
3790
====
3785
3791
@@ -4074,7 +4080,7 @@ lifecycle requirements (e.g. starts and stops some background process):
4074
4080
----
4075
4081
4076
4082
Any Spring-managed object may implement that interface. Then, when the
4077
- ApplicationContext itself starts and stops, it will cascade those calls to all Lifecycle
4083
+ ` ApplicationContext` itself starts and stops, it will cascade those calls to all ` Lifecycle`
4078
4084
implementations defined within that context. It does this by delegating to a
4079
4085
`LifecycleProcessor`:
4080
4086
@@ -4126,7 +4132,7 @@ another option, namely the `getPhase()` method as defined on its super-interface
4126
4132
4127
4133
When starting, the objects with the lowest phase start first, and when stopping, the
4128
4134
reverse order is followed. Therefore, an object that implements `SmartLifecycle` and
4129
- whose getPhase() method returns `Integer.MIN_VALUE` would be among the first to start
4135
+ whose ` getPhase()` method returns `Integer.MIN_VALUE` would be among the first to start
4130
4136
and the last to stop. At the other end of the spectrum, a phase value of
4131
4137
`Integer.MAX_VALUE` would indicate that the object should be started last and stopped
4132
4138
first (likely because it depends on other processes to be running). When considering the
@@ -4136,7 +4142,7 @@ negative phase value would indicate that an object should start before those sta
4136
4142
components (and stop after them), and vice versa for any positive phase value.
4137
4143
4138
4144
As you can see the stop method defined by `SmartLifecycle` accepts a callback. Any
4139
- implementation __must__ invoke that callback's run() method after that implementation's
4145
+ implementation __must__ invoke that callback's ` run()` method after that implementation's
4140
4146
shutdown process is complete. That enables asynchronous shutdown where necessary since
4141
4147
the default implementation of the `LifecycleProcessor` interface,
4142
4148
`DefaultLifecycleProcessor`, will wait up to its timeout value for the group of objects
@@ -4156,14 +4162,14 @@ defining the following would be sufficient:
4156
4162
4157
4163
As mentioned, the `LifecycleProcessor` interface defines callback methods for the
4158
4164
refreshing and closing of the context as well. The latter will simply drive the shutdown
4159
- process as if stop() had been called explicitly, but it will happen when the context is
4165
+ process as if ` stop()` had been called explicitly, but it will happen when the context is
4160
4166
closing. The 'refresh' callback on the other hand enables another feature of
4161
4167
`SmartLifecycle` beans. When the context is refreshed (after all objects have been
4162
4168
instantiated and initialized), that callback will be invoked, and at that point the
4163
4169
default lifecycle processor will check the boolean value returned by each
4164
4170
`SmartLifecycle` object's `isAutoStartup()` method. If "true", then that object will be
4165
4171
started at that point rather than waiting for an explicit invocation of the context's or
4166
- its own start() method (unlike the context refresh, the context start does not happen
4172
+ its own ` start()` method (unlike the context refresh, the context start does not happen
4167
4173
automatically for a standard context implementation). The "phase" value as well as any
4168
4174
"depends-on" relationships will determine the startup order in the same way as described
4169
4175
above.
@@ -4216,8 +4222,8 @@ declared on the `AbstractApplicationContext` class:
4216
4222
[[beans-factory-aware]]
4217
4223
==== ApplicationContextAware and BeanNameAware
4218
4224
4219
- When an `ApplicationContext` creates a class that implements the
4220
- `org.springframework.context.ApplicationContextAware` interface, the class is provided
4225
+ When an `ApplicationContext` creates an object instance that implements the
4226
+ `org.springframework.context.ApplicationContextAware` interface, the instance is provided
4221
4227
with a reference to that `ApplicationContext`.
4222
4228
4223
4229
[source,java,indent=0]
@@ -4237,8 +4243,8 @@ additional functionality. One use would be the programmatic retrieval of other b
4237
4243
Sometimes this capability is useful; however, in general you should avoid it, because it
4238
4244
couples the code to Spring and does not follow the Inversion of Control style, where
4239
4245
collaborators are provided to beans as properties. Other methods of the
4240
- ApplicationContext provide access to file resources, publishing application events, and
4241
- accessing a MessageSource. These additional features are described in
4246
+ ` ApplicationContext` provide access to file resources, publishing application events, and
4247
+ accessing a ` MessageSource` . These additional features are described in
4242
4248
<<context-introduction>>
4243
4249
4244
4250
As of Spring 2.5, autowiring is another alternative to obtain reference to the
@@ -4252,7 +4258,7 @@ parameter that is expecting the `ApplicationContext` type if the field, construc
4252
4258
method in question carries the `@Autowired` annotation. For more information, see
4253
4259
<<beans-autowired-annotation>>.
4254
4260
4255
- When an ApplicationContext creates a class that implements the
4261
+ When an ` ApplicationContext` creates a class that implements the
4256
4262
`org.springframework.beans.factory.BeanNameAware` interface, the class is provided with
4257
4263
a reference to the name defined in its associated object definition.
4258
4264
0 commit comments