- 26 6月, 2014 6 次提交
-
-
由 Rossen Stoyanchev 提交于
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
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
JettyWebsocketClient and StandardWebSocketClient now use the SimpleAsyncTaskExecutor by default to ensure non-blocking connect.
-
由 Rossen Stoyanchev 提交于
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
-
由 Rossen Stoyanchev 提交于
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
-
由 Rossen Stoyanchev 提交于
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
-
- 25 6月, 2014 13 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
SPR-10797
-
由 Rossen Stoyanchev 提交于
-
由 Juergen Hoeller 提交于
ConfigurationClassPostProcessor skips pre-processed bean definitions now (avoiding side effects in case of multiple CCPPs) Issue: SPR-11858
-
由 Juergen Hoeller 提交于
Issue: SPR-11885
-
由 Juergen Hoeller 提交于
Issue: SPR-11906
-
由 Juergen Hoeller 提交于
SelectTag consistently checks specified 'multiple' attribute now, never falling back to forceMultiple in case of user-provided value Issue: SPR-11903
-
由 Sam Brannen 提交于
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
-
由 Juergen Hoeller 提交于
FrameworkPortlet exposes local PortletRequestAttributes in case of pre-bound ServletRequestAttributes as well Issue: SPR-11295
-
由 Juergen Hoeller 提交于
Issue: SPR-11894
-
由 Juergen Hoeller 提交于
Issue: SPR-11898
-
由 Juergen Hoeller 提交于
Issue: SPR-11895
-
由 Brian Clozel 提交于
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
-
- 24 6月, 2014 3 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-11905
-
由 Juergen Hoeller 提交于
AnnotationUtils defensively catches and logs unexpected exceptions from retrieval attempts (proceeding like the annotation wasn't there) Issue: SPR-11874
-
由 Juergen Hoeller 提交于
AnnotationUtils defensively catches unexpected exceptions from retrieval attempts (proceeding like the annotation wasn't there) 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
-
- 22 6月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
This commit deletes all remaining usage of the deprecated SimpleJdbcTemplate class within the framework itself. Issue: SPR-11895
-
- 20 6月, 2014 8 次提交
-
-
由 Sam Brannen 提交于
This commit introduces explicit integration tests that verify Java 8's @Repeatable support for the @Sql annotation. Issue: SPR-7655
-
由 Sam Brannen 提交于
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
-
由 Juergen Hoeller 提交于
Issue: SPR-11887
-
由 Juergen Hoeller 提交于
PathMatchingResourcePatternResolver's findPathMatchingResources needs to check for VFS before checking isJarResource Issue: SPR-11887
-
由 Juergen Hoeller 提交于
Issue: SPR-11876
-
由 Juergen Hoeller 提交于
Also makes the nested SpecificPlatform enum public for Spring Boot to reuse it. Issue: SPR-11877
-
由 Juergen Hoeller 提交于
Issue: SPR-11888
-
由 Juergen Hoeller 提交于
Issue: SPR-11888
-
- 19 6月, 2014 2 次提交
-
-
由 Brian Clozel 提交于
Forums will be shortly deactivated and questions should take place in StackOverflow.
-
由 Juergen Hoeller 提交于
-
- 18 6月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 17 6月, 2014 5 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
This change modifies the SettableListenableFuture implementation to use internally a ListenableFutureTask created with a "settable" Callable. Issue: SPR-11614
-
由 Mattias Severson 提交于
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
-
由 Rossen Stoyanchev 提交于
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
-
- 14 6月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
* pull562: Improve StringUtils#trimAllWhitespace
-