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
This change ensures that SpEL expressions involving floats are
supported natively as opposed to the previous behavior which required
conversion to double, leading to potential downstream conversion
ambiguities.
Issue: SPR-9486
With this commit the Spring Expression Language now supports
increment (++) and decrement (--) operators. These can be
used as either prefix or postfix operators. For example:
'somearray[index++]' and 'somearray[--index]' are valid.
In order to support this there are serious changes to the
evaluation process for expressions. The concept of a
value reference for an expression component has been introduced.
Value references can be passed around and at any time the actual
value can be retrieved (via a get) or set (where applicable). This
was needed to avoid double evaluation of expression components.
For example, in evaluating the expression 'somearray[index++]--'
without a value reference SpEL would need to evaluate the
'somearray[index++]' component twice, once to get the value and
then again to determine where to put the new value. If that
component is evaluated twice, index would be double incremented.
A value reference for 'somearray[index++]' avoids this problem.
Many new tests have been introduced into the EvaluationTests
to ensure not only that ++ and -- work but also that the
introduction of value references across the all of SpEL has
not caused regressions.
Issue: SPR-9751
When obtaining an async result, tests will now await concurrent
processing to complete for the exact amount of time equal to the
actual async timeout value.
Issue: SPR-9875
Before this change View implementations set the response content type
to the fixed value they were configured with.
This change makes it possible to configure a View implementation with
a more general media type, e.g. "application/*+xml", and then set the
response type to the more specific requested media type, e.g.
"application/vnd.example-v1+xml".
Issue: SPR-9807.
Some servlet containers (iPlanet) parse the Accept header and return
multiple values from request.getHeader("Accept"). The HttpHeaders
getAccept method has been updated to accommodate that hopefully
without causing any other issues.
The extra functionality is in effect only if we find only one
MediaType and there is more than one value for the 'Accept' header.
Issue: SPR-9655
Previously UriComponentsBuilder used a regular expression for parsing
query name-value pairs where both name and value were expected to not
contain neither '&', not '='. The idea is that the presence of reserved
characters makes it impossible to guess correctly how to parse the
query string (e.g. a=b&c).
This change relaxes the constraint on query param values, allowing them
to contain '='. In effect '&' is the ultimate separator of name-value
pairs, and any '=' in values is ignored. For example "q=1USD=?EUR" is
interpreted as "q equals '1USD=?EUR'".
Issue: SPR-9832
Prior to this commit, utility methods in JdbcTestUtils interpreted SQL
comments as separate statements, resulting in an exception when such a
script is executed.
This commit addresses this issue by introducing a
readScript(lineNumberReader, String) method that accepts a comment
prefix. Comment lines are therefore no longer returned in the parsed
script. Furthermore, the existing readScript(lineNumberReader) method
now delegates to this new readScript() method, supplying "--" as the
default comment prefix.
Issue: SPR-9593
SpringRunnerContextCacheTests suffers from JDK7-related non-determinism
in values returned from Class#getDeclaredMethods(), which in turn
affects JUnit and its execution of @Test methods.
This commit addresses this issue by introducing an
OrderedMethodsSpringJUnit4ClassRunner that sorts the test methods
alphabetically, which is actually required for
SpringRunnerContextCacheTests to work properly.
Issue: SPR-9789
This commit introduces RequestAndSessionScopedBeansWacTests which
verifies support for request and session scoped beans in the Spring
TestContext Framework (TCF).
This support was actually introduced as an intentional side effect of
the work performed for SPR-5243 through the addition of the new
WebTestExecutionListener.
Issue: SPR-4588
Reverted change for @Bean methods that declare FactoryBean as their return type: The effects of trying to create the FactoryBean to find out about its implementation type are too far-reaching. It's better to recommend declaring a specific return type in the method signature if you want the container to specifically react to your implementation type.
Issue: SPR-9857
Chris Beams
Phillip Webb
Rossen Stoyanchev
Marten Deinum
Satyapal Reddy
Andy Clement
Tim Meighen
Sam Brannen
Juergen Hoeller