This commit refactors changes introduced in 21760a8 as follows:
- Introduce top-level MessageCodeFormatter interface and
DefaultMessageCodesResolver#setMessageCodeFormatter property to allow
for user-defined message code formatting strategies
- Rename DefaultMessageCodesResolver.Style enum => DMCR.Format
- Refactor DefaultMessageCodesResolver.Format to implement the new
MessageCodeFormatter interface
The result is that users have convenient access to common formatting
strategies via the Format enum, while retaining the flexibility to
provide their own custom MessageCodeFormatter implementation if desired.
See DefaultMessageCodesResolverTests#shouldSupport*Format tests for
usage examples.
Issue: SPR-9707
Introduce new 'style' property to DefaultMessageCodesResolver allowing
for alternative message styles. Current styles are PREFIX_ERROR_CODE
and POSTFIX_ERROR_CODE. The default style retains existing behavior.
Issue: SPR-9707
# By Phillip Webb (6) and Chris Beams (1)
* SPR-9692:
Review and polish pull request #132
Support conversion from Enum Interface
Test SpEL unconditional argument conversion
Bypass conversion when possible
Extend conditional conversion support
Refactor GenericConversionService
Additional GenericConversionService Tests
Prior to this commit conversion between like types would often result in
a copy of the object. This can be problematic in the case of large byte
arrays and objects that do not have a default constructor.
The ConversionService SPI now includes canBypassConvert methods that can
be used to deduce when conversion is not needed. Several existing
converters have been updated to ensure they only apply when source and
target types differ.
This change introduces new methods to the ConversionService that will
break existing implementations. However, it anticipated that most users
are consuming the ConversionService interface rather then extending it.
Issue: SPR-9566
Introduce new ConditionalConversion interface that can be applied to
Converter, ConverterFactory or GenericConverter interfaces to make
them conditional. Prior to this commit the only
ConditionalGenericConverter could be conditional.
Issue: SPR-9928
Refactor internal workings of GenericConversionService in order to
better support future enhancements. This commit should not affect
existing behavior.
Issue: SPR-9927
The servlet spec recommends removing path parameters from the
contextPath, servletPath, and pathInfo but not from the requestURI.
This poses a challenge for the UrlPathHelper, which determines the
lookup path by comparing the above.
This change introduces a method that matches the requestURI to the
contextPath and servletPath ignoring path parameters (i.e. matrix
variables) for comparison purposes while also preserving them in the
resulting lookup path.
Allow the body of 'arg-type' XML elements to be used as an alternative to
'match' attribute when defining a 'replace-method' in XML configuration.
This change has been introduced primarily to support the samples printed
in the Apress 'Pro Spring' book.
Issue: SPR-9812
Code introduced in conjunction with SPR-5243 introduced package cycles
between the ~.test.context and ~.test.context.web packages. This was
caused by the fact that ContextLoaderUtils worked directly with the
@WebAppConfiguration and WebMergedContextConfiguration types.
To address this, the following methods have been introduced in
ContextLoaderUtils. These methods use reflection to circumvent hard
dependencies on the @WebAppConfiguration and
WebMergedContextConfiguration types.
- loadWebAppConfigurationClass()
- buildWebMergedContextConfiguration()
Issue: SPR-9924
Prior to this commit, the following two methods in ContextLoaderUtils
contained almost identical loops for traversing the test class
hierarchy:
- resolveContextLoaderClass(Class<?>, String)
- resolveContextConfigurationAttributes(Class<?>)
With this commit, resolveContextLoaderClass() no longer traverses the
class hierarchy. Instead, it now works directly with the resolved list
of ContextConfigurationAttributes, thereby removing code duplication.
Issue: SPR-9918
Code introduced in conjunction with SPR-5243 introduced package cycles
between the ~.test.context.web and ~.test.context.support packages. This
was caused by the fact that ServletTestExecutionListener extended
AbstractTestExecutionListener.
To address this, ServletTestExecutionListener now implements
TestExecutionListener directly.
Issue: SPR-9924
Prior to this commit the MockHttpServletRequest constructor chain set
the preferred local to Locale.ENGLISH. Furthermore, it was possible to
add additional preferred locales "in front" of ENGLISH; however, it was
not possible to delete ENGLISH from the list of preferred locales.
This commit documents the fact that ENGLISH is the default preferred
locale and makes it possible to set the list of preferred locales via a
new setPreferredLocales(List<Locale> locales) method.
Issue: SPR-9724
The MVC namespace and the MVC Java config now allow configuring
CallableProcessingInterceptor and DeferredResultProcessingInterceptor
instances.
Issue: SPR-9914
New afterTimeout and afterCompletion callbacks
afterTimeout can provide a concurrent result to be used instead of the
one that could not be set or returned on time
Interceptor exceptions cause async processing to resume treating the
exception as the concurrent result
Adapter classes for convenient implementation of the interfaces
Issue: SPR-9914
Prior to this commit, the PropertyResolver API (and therefore the
Environment API) allowed callers a choice between
#resolvePlaceholders and #resolveRequiredPlaceholders for low-level
${placeholder} resolution. However, when calling the higher level
#getProperty variants, users had no control over whether property
values returned with unresolvable ${placeholders} would result in an
exception or simply be passed through.
This commit introduces a #setIgnoreUnresolvableNestedPlaceholders
property via ConfigurablePropertyResolver, defaulting to false, the
value of which is respected by AbstractPropertyResolver#getProperty
method implementations. See the new test in
PropertySourcesPropertyResolverTests for usage examples.
Issue: SPR-9569, SPR-9473
- Upgrade to 0.1.6 snapshot of docbook plugin
- Fully qualify PDF artifact name as 'spring-framework-reference.pdf'
instead of former 'spring-reference.pdf'
Issue: SPR-9598
Moving @EnableMBeanExport and its MBeanExportConfiguration
@Configuration class into context.annotation caused a side effect with
ComponentScanningWithLTWTests, which component scans context.annotation
in order to test LTW behavior. Picking up MBeanExportConfiguration
without proper MBean configuration resulted in a NullPointerException
during test execution.
This commit simply filters out all @Configuration classes from the LTW
test's component-scanning directive.
Issue: SPR-8943
Prior to this commit, @EnableMBeanExport was declared in the
jmx.export.annotation package. This makes logical sense, but
nevertheless creates a package cycle, because @EnableMBeanExport depends
on MBeanExportConfiguration which in turn depends on context.annotation
types like @Configuration, @Bean, and @Role.
context.annotation.config.MBeanExportBeanDefinitionParser, on the other
hand already has dependencies on types in jmx.support. Together, this
means that a package cycle was introduced.
The solution to this is simple: move @EnableMBeanExport and friends from
jmx.export.annotation => context.annotation. This has been the strategy
for other @Enable annotations and for the same reasons. It also makes a
kind of logical sense: just like you find <context:mbean-export> and
<context:load-time-weaver> under the context: XML namespace, so too do
you find their @Enable* counterparts under the context.annotation
namespace.
Issue: SPR-8943
Commit 5327a7a37d moved
@EnableSpringConfigured from beans.factory.aspectj =>
context.annotation within the spring-aspects module. This resolved a
package cycle but had the side-effect of causing a "split package" [1]
problem between spring-context and spring-aspects in OSGi-based
classloader environments because the context.annotation package now
exists in both modules.
The simplest and best solution from an OSGi perspective is to relocate
@EnableSpringConfigured and its supporting SpringConfiguredConfiguration
class into a new package. This commit moves both these types into
context.annotation.aspectj, following convention with other such
"aspectj"-qualified packages in the spring-aspects module.
As with the previous move, it is presumed this change will be low-impact
as the "spring-configured" approach to domain object injection is a
niche feature to begin with, and @EnableSpringConfigured has existed in
its current location only since 3.1.2 and this change is being made in
time for 3.1.3.
[1]: http://wiki.osgi.org/wiki/Split_Packages
Issue: SPR-9811, SPR-9441
Prior to this change, LocalJaxWsServiceFactory allowed specifying a WSDL
document URL. Now users may also specify a WSDL document represented as
a Spring Resource object for convenience.
Issue: SPR-9909
Add support for @EnableMBeanExport annotation allowing @Configuration
classes to easily export all MBeans and @ManagedResources from the
Spring application context. The annotation is functionally equivalent
to the XML <context:mbean-export/> element.
Issue: SPR-8943
Chris Beams
Phillip Webb
Rossen Stoyanchev
Sam Brannen
Gareth Davis
Marten Deinum