- Deleted empty AbstractWebSocketClientTests class.
- AbstractServletHandlerMethodTests and AbstractHttpRequestTests are
now actually declared as abstract.
- The following classes are not abstract but currently have an
"Abstract" prefix and therefore get ignored by the Gradle build.
This commit renames each of these by deleting the "Abstract" prefix.
- AbstractFlashMapManagerTests
- AbstractMappingContentNegotiationStrategyTests
- AbstractSockJsServiceTests
- AbstractWebSocketHandlerRegistrationTests
The Servlet API does not provide notifications when a client
disconnects, see see https://java.net/jira/browse/SERVLET_SPEC-44.
Therefore network IO failures may occur simply because a client has
gone away. Before this change that could fill logs with unnecessary
stack traces.
After this change we make a best effort to identify such network
failures, on a per-server basis (tested with Jetty, Tomcat, Glassfish,
and WildFly), and log them under a separate log category.
A simple one-line message is logged at DEBUG level (i.e. no stack trace)
while a full stack trace is shown at TRACE level.
Issue: SPR-11438
Before this change CompositeMessageConverter had a ContentTypeResolver
field that was in turn set on all contained converters.
After this change that field is removed and effectively
CompositeMessageConverter is a simple container of other converters.
Each converter in turn must have been configured with a
ContentTypeResolver.
Doing so means it is less likely to have unexpected consequences when
configuring converters, the ContentTypeResolver set in the composite
converter overriding the one configured in a contained converter.
Also commit 676ce6 added default ContentTypeResolver initialization
to AbstractMessageConverter, which ensures that converters are still
straight forward to configure.
Issue: SPR-11462
Before this change, when a client subscribed to a "user" destination
(e.g. /user/foo), actual messages received in response to that
subscription contained the server-translated, unique user destination
(e.g. /foo-user123).
This is not an issue for clients such as stomp.js since the
subscription is unique and sufficient to match subscription responses.
However, other STOMP clients do additional checks on the destination
of the subscription and the response.
This change ensures that messages sent to clients on user destionations
always contain a destination that matches the one on the original
subscription.
Issue: SPR-11423
The interface is to be implemented in addition to
java.security.Principal when Principal.getName() is not globally unique
enough for use in user destinations.
Issue: SPR-11327
sockjs-client expects a prelude to be written on every request with
streaming transports. The protocol tests don't make this clear and
don't expose this issue.
The test case for SPR-11183 (writing 20K messages in succession) did
expose the issue and this commit addresses it.
Issue: SPR-11183
This change adds a protected method to DefaultHandshakeHandler to
determine the user for the WebSocket session. By default it's
implemeted to obtain it from the request.
Issue: SPR-11228
The Jetty ServletWebUpgradeRequest implements getUserPrincipal to
return the Principal from the HttpServletRequest on the upgrade.
This change ensures we can fall back on that.
However the JettyRequestUpgradeStrategy still passes the user from
HttpServletRequest from the upgrade, in order to work with Jetty
9.0.x and avoid running into this 9.1.x issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=423118
The observed behavior was that the client does not get a response from
the WebSocket HTTP handshake. On the server the handshake actually
succeeds, the response is set correctly to status 101, and the
WebSocketHandler gets notified of the successfully established
connection.
This change flushes the ServletResponse just before returning from the
GlassfishRequestUpgradeStrategy. This is actually what Glassfish's own
TyrusServletFilter does as well at the end along with a comment that it
is a possible bug.
This commit adds an XML namespace equivalent of @EnableWebSocket and
@EnableWebSocketMessageBroker. Those are <websocket:handlers> and
<websocket:message-broker> respectively.
Examples can be found in the test suite.
This commit also alters the way MessageHandler's subscribe to their
respective MessageChannel's of interest. Rather than performing the
subscriptions in configuration code, the message channels are now
passed into MessageHandler's so they can subscribe themselves on
startup.
Issue: SPR-11063
Apply consistent styling to new classes introduced in Spring 4.0.
- Javadoc line wrapping, whitespace and formatting
- General code whitespace
- Consistent Assert.notNull messages
@EnableWebSocketMessageBroker message channel configuration can now be
customized via WebSocketMessageBrokerConfigurer. It is necessary to
make this easy and even required as part of the basic configuration
since by default the message channels are backed by a thread pool of
size 1, not suitable for production use.
Issue: SPR-11023
Two concurrent threads should not send a message on a single WebSocket
session at the same time, for example see:
http://docs.oracle.com/javaee/7/api/javax/websocket/RemoteEndpoint.Basic.html
In StompSubProtocolHandler it is quite possible that multiple messages
may be broadcast to a single WebSocket client concurrently.
This change adds synchronization around the sending of a message to a
specific cilent session.
Issue: SPR-11023
Rossen Stoyanchev
Sam Brannen
Juergen Hoeller
Brian Clozel
Phillip Webb