When using PropertiesLoaderSupport implementations (principally
PropertyPlaceholderConfigurer), an assumption was made that any
Resource representing a set of properties must be file-based. SPR-7547
exposed the fact that if a non-file-based Resource implementation such
as ByteArrayResource were passed in, an IllegalStateException would be thrown
from the AbstractResource base class' implementation of getFilename().
This is now patched, and PropertiesLoaderSupport implementations treat
Resource implementations equally, regardless of file-orientation.
See also SPR-7552.
All <section/> elements in beans.xml >=~ 500 lines have been broken out
into separate documents with DOCTYPE 'section'. This refactoring makes
working with these files much easier in wysiwyg editors (namely
oXygen Author).
For consistency, this same refactoring should be applied to all other
chapters much larger than 1500 lines, such as aop.xml (3861), mvc.xml
(3466), jdbc.xml (3042), and so on.
beans.xml and the new section files have also been formatted for
consistency and to avoid whitespace diffs as much as possible into the
future.
JavaDoc and reference docs now warn developers against interacting with
bean instances within BeanFactoryPostProcessor implementations in order
to avoid premature bean instantiation.
See SPR-7450 for an example of a third-party BFPP
(OAuthTokenLifecycleRegistryPostProcessor) prematurely instantiating
a FactoryBean instance, such that bean post-processing is bypassed
and autowired injection (via @Inject) never occurs.
XFire is now CXF (per http://xfire.codehaus.org), and given that Spring
does not actually ship with any explicit XFire support, it makes sense
to remove the documentation completely. CXF does provide support for
writing services with Spring, and they provide their own documentation.
See http://cxf.apache.org/docs/writing-a-service-with-spring.html
Chapter 27 covered @Required and RequiredAnnotationBeanPostProcessor but
did not hold together as a chapter unto itself. The IoC chapter already
makes mention of @Required and RequiredAnnotationBeanPostProcessor,
though not in quite as much detail as Chapter 27 did. Links have been
updated throughout to reference these sections and Chatper 27 has been
eliminated entirely.
Prior to change, there were 175 instances of <methodname/> elements
including parentheses (e.g.: <methodname>foo()</methodname>, and
36 instances without.
Now all 211 instances include parentheses for consistency.
Documentation now:
- Reflects generic use of ApplicationListener interface
- Demonstrates use of ApplicationEventPublisher(Aware) instead of
ApplicationContext(Aware) for publishing custom events
- Provides a more complete narrative as to how each of the publisher,
listener, and event objects interact with one another
<programlisting/> elements must contain no newlines at beginning or end.
The following is an example of what not to do:
<programlisting><![CDATA[
package com.foo.bar;
class XFoo implements Foo<X> {
}]]>
</programlisting>
This leaves newlines at the beginning and end of the programlisting
panel within the PDF. Instead, do it like this:
<programlisting><![CDATA[package com.foo.bar;
class XFoo implements Foo<X> {
}]]></programlisting>
- The sentence at the end of section 5.5.5 now refers to the
<mvc:annotation-driven conversion-service="..."/> example at the end
of section 5.6.
- The sentence at the end of section 5.5.5 refers to the
FormatterConversionServiceFactoryBean section that follows.
- 'dependency-check' attribute of the <bean/> element was removed
in the spring-beans-3.0 XSD; documentation now reflects this change.
- 'autodetect' was removed from the enumeration of possible values
for autowire mode in the spring-beans-3.0 XSD; documentation now
reflects this change.
Note that the underlying functionality for these values has not been
removed from Spring Core. Users of Spring 3.0 who still need this
support may choose to use spring-beans-2.5.xsd in order to preserve
backward-compatibility.
Typo on the name of the @Autowired annotation: @Autowire -> @Autowired
Usage of the @Value annotation: ${jdbcProperties.url} -> ${jdbc.url} (inside section "Declaring @Configuration classes as plain Spring <bean/> elements").
Jeremy Grelle
Chris Beams
Michael Isvy
Arjen Poutsma
Andy Clement
Juergen Hoeller
Oliver Gierke