Introduce FeatureSpecification interface and implementations
FeatureSpecification objects decouple the configuration of
spring container features from the concern of parsing XML
namespaces, allowing for reuse in code-based configuration
(see @Feature* annotations below).
* ComponentScanSpec
* TxAnnotationDriven
* MvcAnnotationDriven
* MvcDefaultServletHandler
* MvcResources
* MvcViewControllers
Refactor associated BeanDefinitionParsers to delegate to new impls above
The following BeanDefinitionParser implementations now deal only
with the concern of XML parsing. Validation is handled by their
corresponding FeatureSpecification object. Bean definition creation
and registration is handled by their corresponding
FeatureSpecificationExecutor type.
* ComponentScanBeanDefinitionParser
* AnnotationDrivenBeanDefinitionParser (tx)
* AnnotationDrivenBeanDefinitionParser (mvc)
* DefaultServletHandlerBeanDefinitionParser
* ResourcesBeanDefinitionParser
* ViewControllerBeanDefinitionParser
Update AopNamespaceUtils to decouple from XML (DOM API)
Methods necessary for executing TxAnnotationDriven specification
(and eventually, the AspectJAutoProxy specification) have been
added that accept boolean arguments for whether to proxy
target classes and whether to expose the proxy via threadlocal.
Methods that accepted and introspected DOM Element objects still
exist but have been deprecated.
Introduce @FeatureConfiguration classes and @Feature methods
Allow for creation and configuration of FeatureSpecification objects
at the user level. A companion for @Configuration classes allowing
for completely code-driven configuration of the Spring container.
See changes in ConfigurationClassPostProcessor for implementation
details.
See Feature*Tests for usage examples.
FeatureTestSuite in .integration-tests is a JUnit test suite designed
to aggregate all BDP and Feature* related tests for a convenient way
to confirm that Feature-related changes don't break anything.
Uncomment this test and execute from Eclipse / IDEA. Due to classpath
issues, this cannot be compiled by Ant/Ivy at the command line.
Introduce @FeatureAnnotation meta-annotation and @ComponentScan impl
@FeatureAnnotation provides an alternate mechanism for creating
and executing FeatureSpecification objects. See @ComponentScan
and its corresponding ComponentScanAnnotationParser implementation
for details. See ComponentScanAnnotationIntegrationTests for usage
examples
Introduce Default[Formatting]ConversionService implementations
Allows for convenient instantiation of ConversionService objects
containing defaults appropriate for most environments. Replaces
similar support originally in ConversionServiceFactory (which is now
deprecated). This change was justified by the need to avoid use
of FactoryBeans in @Configuration classes (such as
FormattingConversionServiceFactoryBean). It is strongly preferred
that users simply instantiate and configure the objects that underlie
our FactoryBeans. In the case of the ConversionService types, the
easiest way to do this is to create Default* subtypes. This also
follows convention with the rest of the framework.
Minor updates to util classes
All in service of changes above. See diffs for self-explanatory
details.
* BeanUtils
* ObjectUtils
* ReflectionUtils
Changed the documentation to correctly state that B(F)PP are instantiated eagerly no matter if they are explicitly marked as to be lazy initialized or the default-lazy-init attribute is used at a <beans /> element.
* documented that @Async can't be used in conjunction with lifecycle callbacks such as @PostConstruct
* provide sample for workaround
* added semantic markup for code
- Relocate and fix typos in interface-based @RequestMapping tip (SPR-7537)
- Fix typos in constructor-arg 'name' disambiguation section (SPR-7443)
- Polish whitespace in DefaultServletHttpRequestHandler (SPR-7553)
Extended documentation to include hints on what to
consider when working with proxied controllers.
Explained the necessity of moving @RequestMapping
annotations to the interface or use proxy-target-
class="true".
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.
Costin Leau
Chris Beams
Sam Brannen
Rossen Stoyanchev
Michael Isvy
Oliver Gierke
Arjen Poutsma
Jeremy Grelle