Users can not mix and match between "inner bean" argument resolver and "external bean" argument resolver. This commit only focuses only on argument-resolver, while the support could be extended to return value handlers as well.
Issue: SPR-11927
This commit fixes cases where part of the URI was mistaken for the
userinfo when:
* the URI did not contain any path
* the query string contained the "@"
Issue: SPR-11964
This change removes most logging at INFO level and also ensures the
amount of information logged at DEBUG level is useful, brief, and
not duplicated.
Also added is custom logging for STOMP frames to ensure very readable
and consise output.
Issue: SPR-11934
This change adds collection of stats in key infrastructure components
of the WebSocket message broker config setup and exposes the gathered
information for logging and viewing (e.g. via JMX).
WebSocketMessageBrokerStats is a single class that assembles all
gathered information and by default logs it once every 15 minutes.
Application can also easily expose to JMX through an MBeanExporter.
A new section in the reference documentation provides a summary of
the available information.
Issue: SPR-11739
Commit 5fe8f52 introduced a support for @Priority as an alternative to
@Primary but it broke the semantic of the priority value. This commit
fixes this inconsistency.
As for @Order, the lowest value means the highest priority so if
several beans are candidates for injection, the one having the lowest
value will be used.
Issue: SPR-10548
This commit removes the immediate package dependency cycle between the context and jmx packages. A specific callback arrangement will follow in time for 4.1 RC1; at this point, it's temporarily back to registration kicked off by afterPropertiesSet again.
Issue: SPR-8045
Prior to this change, AbstractHttpReceivingTransportHandler had a direct
dependency on a Jacckson Exception (checking that exception in a catch
clause). This can cause issues for applications that don't have that
dependency.
This commit removes that direct dependency, still logging the
appropriate log messages using a parent exception (IOException) and
reflection.
Issue: SPR-11963
Commit eea230f introduced a regression by adding a support for the
"result" variable in SpEL expression for @CachePut. As such expressions
cannot be evaluated upfront anymore, any method that contains both
@Cacheable and @CachePut annotations are always executed even when
their conditions are mutually exclusive.
This is an example of such mutual exclusion
@Cacheable(condition = "#p1", key = "#p0")
@CachePut(condition = "!#p1", key = "#p0")
public Object getFooById(Object id, boolean flag) { ... }
This commit updates CacheEvaluationContext to define a set of
unavailable variables. When such variable is accessed for a given
expression, an exception is thrown. This is used to restore the
evaluation of the @CachePut condition upfront by registering "result"
as an unavailable variable.
If all @CachePut operations have been excluded by this upfront check,
the @Cacheable operation is processed as it was before. Such upfront
check restore the behavior prior to eea230f.
Issue: SPR-11955
Prior to this commit, cache operations mentioning a qualifier led to
a lookup for the same PlatformTransactionManager over and over again.
The same applied when a transactionManager bean name was specified on
the interceptor.
This commit adds a cache to store the reference of such transaction
managers. As a convenience, the default PlatformTransactionManager is
also initialized if it has not been through configuration.
Issue: SPR-11954
This commit introduces unit tests that attempt to reproduce the problem
described in Spring Boot issue 885; however, the tests pass and
therefore do not confirm the reported problem.
See: https://github.com/spring-projects/spring-boot/issues/885
This commit supports two additional methods of the MessageProducer
interface as from JMS 2.0
An integration test infrastructure is necessary to be able to test
those scenario: this is taken care of in a separated initiative.
Issue: SPR-11950
Historically, Spring's JUnit 3.8 TestCase class hierarchy supported
programmatic transaction management of "test-managed transactions" via
the protected endTransaction() and startNewTransaction() methods in
AbstractTransactionalSpringContextTests.
The Spring TestContext Framework (TCF) was introduced in Spring 2.5 to
supersede the legacy JUnit 3.8 support classes; however, prior to this
commit the TCF has not provided support for programmatically starting
or stopping the test-managed transaction.
This commit introduces a TestTransaction class in the TCF that provides
static utility methods for programmatically interacting with
test-managed transactions. Specifically, the following features are
supported by TestTransaction and its collaborators.
- End the current test-managed transaction.
- Start a new test-managed transaction, using the default rollback
semantics configured via @TransactionConfiguration and @Rollback.
- Flag the current test-managed transaction to be committed.
- Flag the current test-managed transaction to be rolled back.
Implementation Details:
- TransactionContext is now a top-level, package private class.
- The existing test transaction management logic has been extracted
from TransactionalTestExecutionListener into TransactionContext.
- The current TransactionContext is stored in a
NamedInheritableThreadLocal that is managed by
TransactionContextHolder.
- TestTransaction defines the end-user API, interacting with the
TransactionContextHolder behind the scenes.
- TransactionalTestExecutionListener now delegates to
TransactionContext completely for starting and ending transactions.
Issue: SPR-5079
Juergen Hoeller
Rossen Stoyanchev
Agim Emruli
Brian Clozel
Stephane Nicoll
Phillip Webb
Sam Brannen