Prior to this change, location paths used for resource handling would
not allow "non-cleaned, relative paths" such as
`file://home/user/static/../static/`. When checking if the resolved
resource's path starts with the location path, a mismatch would happen
when comparing for example:
* the location `file://home/user/static/../static/`
* and the resource `file://home/user/static/resource.txt`
This commit cleans the location path before comparing it to the resource
path.
Issue: SPR-12624
This commit allows the use of "protcol relative URLs" (i.e. URLs without
scheme, starting with `//`), often used to serve resources automatically
from https or http with third party domains.
This syntax is allowed by RFC 3986.
Issue: SPR-12632
This commit fixes the default value for the contextRelative attribute of
a RedirectView, when this view is registered via a
RedirectViewController in XML. The value is set to true.
Note that the default value for this is correctly documented in
spring-mvc-4.1.xsd. Also, the documentation and implementation for its
javadoc counterpart also enforces true as a default value.
Issue: SPR-12607
Update documentation to explicitly mention that the cache interceptor
must be fully initialized to provide the expected behavior and therefore
initialization code should not rely on this feature, i;e. typically in
PostConstruct callback.
Since the Transactional infrastructure has the exact same infrastructure,
update that section of the doc as well.
Issue: SPR-12700
Previously, one could only set the list of bean names to exclude from
auto-detection and there was no way to add additional bean names.
MBeanExporter now exposes a addExcludedBean method that can be invoked
during the initialization phase to add bean names to ignore.
Issue: SPR-12686
This change deprecates the maxRequestSize property and adds
maxResponseSize instead. The latter is required to create Netty's
HttpObjectAggregator and aggregates responses.
The maxRequestSize property is already removed in the master branch
and will not be available starting with 4.2.
Issue: SPR-12623
Prior to this change when adding subscriptions
DefaultSubscriptionRegistry (incorrectly) made a copy of the given map
for its "access" cache rather than for its "update" cache.
Issue: SPR-12665
Provide an additional hook-point for YamlProcessor subclasses willing to
change how the Yaml instance is configured. Also expose the default
StrictMapAppenderConstructor so that they can compose a custom instance
with it.
Issue: SPR-12671
Spring Framework 4.0 introduced support for using test-related
annotations as meta-annotations in the Spring TestContext Framework
(TCF) in order to create custom composed annotations within a test
suite; however, the detection of default @Configuration classes in test
classes was not updated to search for @Configuration declared as a
meta-annotation. Specifically, AnnotationConfigContextLoaderUtils
invokes Class.isAnnotated() which only searches for annotations
declared directly on the class in question.
This commit addresses this issue by refactoring the
isDefaultConfigurationClassCandidate() method in
AnnotationConfigContextLoaderUtils so that it uses
AnnotationUtils.findAnnotation() instead of Class.isAnnotated() for
detecting the presence of the @Configuration annotation, either
directly or as a meta-annotation.
Issue: SPR-12659
(cherry picked from commit 2d918380f0)
In order to allow DefaultActiveProfilesResolver to be reused (e.g., via
extension or delegation), the check which asserts that the 'resolver'
attribute of @ActiveProfiles is not set to a customer resolver class
has been removed.
Issue: SPR-12611
(cherry picked from commit 276712dcd1)
JUnit 4.9 introduced a regression in BlockJUnit4ClassRunner.runChild()
such that exceptions thrown from methodBlock() cause the current test
execution to abort immediately. As a result, the failing test method is
unrooted, and subsequent test methods are never invoked. Furthermore,
RunListeners registered with JUnit are not properly notified.
In conjunction with SPR-11908, SpringJUnit4ClassRunner was updated to
use the aforementioned changes to BlockJUnit4ClassRunner.runChild().
Consequently, SpringJUnit4ClassRunner now suffers from the same
regression.
This commit addresses this issue by ensuring that any exceptions thrown
during the invocation of methodBlock() are properly wrapped in a JUnit
Fail Statement.
Issue: SPR-12613
(cherry picked from commit b81c522ee1)
Fix a regression introduced by 961574bd17 that prevents a proper lookup
of the default transaction manager by name as the absence of a qualifier
is represented by an empty string (passing the faulty null check).
Issue: SPR-12577
The following two refinements have been added:
1) SockJS doesn't support binary messages so don't even try
2) don't bother if payload.length == 0
Issue: SPR-12475
Previously the default settings of a custom HttpClient were always
ignored since a RequestConfig instance was always set no matter if
some customizations were applied or not.
This commit keeps an internal RequestConfig object instance that is
only initialized if the user applies a customization. If he does not, the
default settings of the HttpClient are used as it should.
Note that if the HttpComponents API exposed the default RequestConfig
of a given HttpClient, we would be able to merge our customizations with
the one specified by the client. Unfortunately, such API does not exist
and the "defaultSettingsOfHttpClientLostOnExecutorCustomization" test
illustrates that limitation.
Issue: SPR-12540
One more (and hopefully last) attempt at making sure
determineTransactionManager does not break existing use cases.
This commit prevents any lookup if no transaction attributes are set
which is more compliant with the original version and prevents a lookup
if a non existing bean name is provided explicitly (as it can be the case
with Spring Boot).
Issue: SPR-12541
The fix in cec26e9 for SPR-12541 actually introduced a regression
when the interceptor is enabled on a method that does not require any
transaction. In such a case we try to locate the default
PlatformTransactionManager instead of just returning what we have (that
is null).
This commit updates the determineTransactionManager condition again to
take that use case into account again.
Issue: SPR-12541
In order to avoid breaking changed due to the upcoming SockJS 1.0
release (see SPR-12422 for more details) and link to the right
SockJS documentation version, we now explicitly specify that we
support SockJS protocol 0.3.3 and SockJS client 0.3.x.
Brian Clozel
Stephane Nicoll
Rossen Stoyanchev
Sam Brannen
Juergen Hoeller
mgooty
Sebastien Deleuze