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.
Before this change attributes listed with @SessionAttributes would not
be saved in the session when there was a redirect and the controller
method declared a parameter of type RedirectAttributes.
This change ensures it's the "default" model that is always the one
checked for @SessionAttributes under all circumstances since
RedirectAttributes is really only meant to provide String values to
insert into or append to the the redirect URL.
Issue: SPR-12542
Previously, if a bean has a scoped proxy and is annotated to be exposed
to the JMX domain, both the scoped proxy and the target instance were
exposed in the JMX domain, resulting in a duplicate entries. Worse, if
such bean defines an explicit name, the application wouldn't start
because of a name conflict.
This commit deals explicitely with scoped proxy and make sure to only
expose the relevant bean.
Issue: SPR-12529
Prior to this commit it was not possible to easily customize the
connection request timeout used by the HttpClient. Both
`HttpComponentsClientHttpRequestFactory` and
`HttpComponentsClientHttpRequestFactoryTests` have been updated to
support a `connectionRequestTimeout` property.
Issue: SPR-12166
Update the documentation to better reflect the fact that a @EnableCaching
configuration class must implement CachingConfigurer in order to provide
advanced customizations to the cache abstraction.
Previously, HttpComponentsHttpInvokerRequestExecutor was not compatible
with the new API of HttpComponents 4.3. Specifically, it is not possible
to update the socket and read timeouts on the HttpClient itself anymore.
We actually already updated HttpComponentsClientHttpRequestFactory for a
similar problem in SPR-11442: if we detect an older HttpClient
implementation, we update the timeout directly on the client. If that's
not the case, we keep the value in the factory itself and use it when a
new HttpRequest needs to be created.
This commit also uses the new API to create a default HttpClient and
therefore requires HttpComponents 4.3. As mentioned above, it is still
possible to use deprecated HttpClient instances against this executor.
Issue: SPR-11113
Without this change when the operands to an == are a mix of a
reference type and a primitive, the failure to box the primitive
would result in a verifyerror when the compiled code is loaded.
Issue: SPR-12557
Update the developer guide to explicitly reference the (inferred)
constant introduced in 38e90105a0.
Also emphasis the fact that the (inferred) mode is enabled by default
with Java config and how to disable it if necessary.
Issue: SPR-12534
Previously, cache transaction managers may be retained outside the
boundaries of an application context with AspectJ since an aspect is
basically a singleton for the current class loader.
This commit adds a "clearTransactionManagerCache" that is similar to the
"clearMetadataCache" introduced in CacheAspectSupport: whenever the
context is disposed, the cache is cleared to remove any reference to a
transaction manager defined by that context.
Issue: SPR-12518
SPR-11954 introduced a regression that when the "default" transaction
manager is cached, qualified transaction managers are not taken into
account anymore.
This commit rework the "determineTransactionManager" condition to
favor qualifier and "named" transaction managers. If none of these apply,
the default transaction manager is used as it should.
Also reworked the caching infrastructure so that a single cache holds
all transaction manager instances.
Issue: SPR-12541
This commit introduces test methods in CollectionFactoryTests that
demonstrate how the APIs for createCollection() and createMap() are not
type-safe, specifically regarding the use of generics, raw types, and
casting.
SPR-12483 introduced automatic type conversion support for EnumSet and
EnumMap. However, the corresponding changes in CollectionFactory
contradict the existing contract for the "create approximate" methods
by creating a copy of the supplied set or map, thereby potentially
including elements in the returned collection when the returned
collection should in fact be empty.
This commit addresses this issue by ensuring that the collections
returned by createApproximateCollection() and createApproximateMap()
are always empty.
Furthermore, this commit improves the Javadoc throughout the
CollectionFactory class.
Issue: SPR-12533
This commit introduces test methods in CollectionFactoryTests that
demonstrate how the APIs for createApproximateCollection() and
createApproximateMap() are not type-safe, specifically regarding the use
of generics, raw types, and casting.
Only compute the error message to display when the generated key is
actually null instead of using Assert.notNull as the cache operation
'toString()' method is non trivial and gets computed regardless of the
result.
Issue: SPR-12527
JUnit 4.12 created a 'public' version of the previously 'internal'
AssumptionViolatedException.
This commit upgrades Spring's Assume class to use this new public
version.
This commit introduces superfluous casts in CollectionFactory to
address a bug in Eclipse 4.4.1 that prevents the code from compiling
within Eclipse. Specifically, without these casts Eclipse displays the
following error for use of the EnumSet.copyOf() and EnumSet.noneOf()
methods:
Type mismatch: cannot convert from EnumSet<Enum<Enum<E>>> to
Collection<E>
Stephane Nicoll
Sebastien Deleuze
Rossen Stoyanchev
Juergen Hoeller
Stephane Nicoll
Andy Clement
Sam Brannen
Brian Clozel