Commit 5d2e6f enabled the setRemoveOnCancelPolicy of the SockJS
ScheduledThreadPoolExecutor by default. However that property is only
available in JDK 1.7 or later. This change fixes the issue and
introduces an extension of ThreadPoolTaskScheduler for for use with
SockJS which is necessary in any case since ThreadPoolTaskScheduler
does not expose the underlying ScheduledThreadPoolExecutor otherwise.
Issue: SPR-11918
This change sets the removeOnCancelPolicy on the SockJS
ScheduledThreadPoolExecutor to true. This ensures that cancelled
tasks are removed immediately to avoid the "unbounded retention
of cancelled tasks" that is mentioned in the Javadoc of
ScheduledThreadPoolExecutor:
"By default, such a cancelled task is not automatically removed from
the work queue until its delay elapses. While this enables further
inspection and monitoring, it may also cause unbounded retention of
cancelled tasks. To avoid this, set setRemoveOnCancelPolicy to true,
which causes tasks to be immediately removed from the work queue at
time of cancellation."
Issue: SPR-11918
This change ensures the server "WebSocketHandler" is notified of the
opening of a session before writing the open frame to the remote
handler. Any messages sent by the server "WebSocketHandler" while
getting notified of the opening get cached and flushed after the open
frame has been written.
This change introduces locking in AbtractHttpSockJsSession to guard
access to the HTTP response. The goal is to prevent contention between
client requests to receive messages (i.e. long polling) and
the application trying to write.
Issue: SPR-11916
This change adds a new implementation of WebSocketClient that can
connect to a SockJS server using one of the SockJS transports
"websocket", "xhr_streaming", or "xhr". From a client perspective
there is no implementation difference between "xhr_streaming" and
"xhr". Just keep receiving and when the response is complete,
start over. Other SockJS transports are browser specific
and therefore not relevant in Java ("eventsource", "htmlfile" or
iframe based variations).
The client loosely mimics the behavior of the JavaScript SockJS client.
First it sends an info request to find the server capabilities,
then it tries to connect with each configured transport, falling
back, or forcing a timeout and then falling back, until one of the
configured transports succeeds.
The WebSocketTransport can be configured with any Spring Framework
WebSocketClient implementation (currently JSR-356 or Jetty 9).
The XhrTransport currently has a RestTemplate-based and a Jetty
HttpClient-based implementations. To use those to simulate a large
number of users be sure to configure Jetty's HttpClient executor
and maxConnectionsPerDestination to high numbers. The same is true
for whichever underlying HTTP library is used with the RestTemplate
(e.g. maxConnPerRoute and maxConnTotal in Apache HttpComponents).
Issue: SPR-10797
Prior to this commit, the Spring TestContext Framework (TCF) was
compatible with JUnit 4.5 or higher.
This commit effectively raises the minimum version of JUnit that is
officially supported by the TCF to JUnit 4.9, thereby aligning with
similar upgrades made in the Spring Framework 4.0 release (i.e.,
upgrading minimum requirements on third-party libraries to versions
released mid 2010 or later).
Issue: SPR-11908
Prior to this commit, one of the available strategies for resolving
resources was the PrefixResourceResolver. Reconsidering the core goal of
this resolver and the FingerprintResourceResolver, we found that the
true core feature is versioning static resources application-wide.
This commit refactors both Resolvers by:
* having only on VersionResourceResolver
* that resolver takes a mapping of paths -> VersionStrategy
* provided VersionStrategy implementations are ContentBasedVS
(previously FingerprintRR), FixedVS (previously PrefixRR)
One can add a VersionResourceResolver like this:
Map<String, VersionStrategy> versionStrategies = new HashMap<>();
versionStrategies.put("/**/*.js", new PrefixVersionStrategy("prefix"));
versionStrategies.put("/**", new ContentBasedVersionStrategy());
VersionResourceResolver versionResolver = new VersionResourceResolver();
versionResolver.setVersionStrategyMap(versionStrategies);
List<ResourceResolver> resolvers = new ArrayList<ResourceResolver>();
resolvers.add(versionResolver);
resolvers.add(new PathResourceResolver());
Issue: SPR-11871
This is analogous to what the JVM does for cases where the annotation type itself isn't present on the classpath. We're effectively extending that policy to values referenced within an annotation declaration.
Issue: SPR-11874
Prior to this commit, SQL script annotations and related classes in the
TestContext framework (TCF) were named DatabaseInitializer*. However,
these annotations are not used only for initialization and are
therefore misleading when used for cleaning up the database.
This commit refines the names of annotations and related classes for
configuring SQL scripts to be executed for integration tests in the TCF
as follows:
- @DatabaseInitializer -> @Sql
- @DatabaseInitializers -> @SqlGroup
- DatabaseInitializerTestExecutionListener -> SqlScriptsTestExecutionListener
A special thanks goes out to the following attendees of the Zurich
Hackergarten meeting last night for their collective brainstorming:
@aalmiray, @atsticks, @ollin, @simkuenzi, @tangresh, @vyazelenko.
Issue: SPR-7655
This change modifies the SettableListenableFuture implementation to use
internally a ListenableFutureTask created with a "settable" Callable.
Issue: SPR-11614
A SettableListenableFuture implementation of Spring's ListenableFuture
The class is inspired by Google Guava’s
com.google.common.util.concurrent.SettableFuture, but this
implementation uses ReentrantReadWriteLock and CountDownLatch
internally to handle thread synchronization.
Issue: SPR-11614
After this change, java.util.Optional is supported with @RequestParam,
@RequestHeader, and @MatrixVariable arguments in Java 8. When Optional
is used the required flag is effectively ignored.
Issue: SPR-11829
Prior to this commit, StringUtils#trimAllWhitespace(String str) was
unecessary slower. Using sb.deleteCharAt(index) leads to a complete
copy of the char[]
Prior to this commit, the CssLinkResourceTransformer would transform
"external resources", i.e. resources not served by the web application.
This commit only allows transformation for resources which path don't
contain scheme such as "file://" or "http://". Only relative and
absolute paths for resources served by the webapp are valid.
Issue: SPR-11860
Prior to this commit, AntPathMatcher had been refactored for SPR-6741.
During that process, a key feature has been removed:
When comparing two patterns, pattern elements (*, {}, etc) are counted
to score those patterns. When a pattern ends with ".*", the ending
wildcard should not be counted against pattern elements for this
pattern.
This commit reintroduces that behavior.
Issue: SPR-6741
Prior to this commit, "**" and "*" pattern elements had
the same priority when comparing two patterns.
So when comparing several patterns, the computed order was:
1- /hotels/{hotel}/bookings/{booking}
2- /hotels/**
3- /hotels/{hotel}/bookings/{booking}/customer/{customer}
This commit updates the comparator so that patterns ending
with "**" (a.k.a "catch-all" patterns) are less specific than
the others; in the previous example, the 2nd pattern would
then end up last.
This commit also optimizes the comparator implementation.
Issue: SPR-6741
Since SPR-11486 and SPR-10163, Path Matching options can be configured
to customize path matching options for RequestMappingHandlerMapping.
Prior to this commit, the defined pathMatcher and pathHelper instances
were only used in RequestMappingHandlerMapping.
This commit now registers pathMatcher and pathHelper beans under
well-known names and share them with several HandlerMappings beans,
such as ViewControllerMappings and ResourcesMappings.
Issue: SPR-11753
Rossen Stoyanchev
Juergen Hoeller
Sam Brannen
Brian Clozel
Mattias Severson
Stephane Nicoll
hengyunabc