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
Fix a variety of typos throughout the project, primarily in
comments (javadoc or otherwise) but also in a handful of log messages
and a couple exception messages.
ISSUE: SPR-11123
The addition of SubProtocolCapable simplifies configuration since it is
no longer necessary to explicitly configure DefaultHandshakeHandler
with a list of supported sub-protocols. We will not also check if the
WebSocketHandler to use for the WebSocket request is an instance of
SubProtocolCapable and obtain the list of sub-protocols that way. The
provided SubProtocolWebSocketHandler does implement this interface.
Issue: SPR-11111
Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.
Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.
Issue: SPR-11064
Before this change spring-messaging contained a few WebSocket-related
classes including WebSocket sub-protocol support for STOMP as well
as @EnableWebSocketMessageBroker and related configuration classes.
After this change those classes are located in the spring-websocket
module under org.springframework.web.socket.messaging.
This means the following classes in application configuration must
have their packages updated:
org.springframework.web.socket.messaging.config.EnableWebSocketMessageBroker
org.springframework.web.socket.messaging.config.StompEndpointRegistry
org.springframework.web.socket.messaging.config.WebSocketMessageBrokerConfigurer
MessageBrokerConfigurer has been renamed to MessageBrokerRegistry and
is also located in the above package.
Before this change the amount of logging was too little or too much
with TRACE turned on. This change separates useful debugging
information and logs it under DEBUG and leaves more detailed
information to be logged under TRACE.
Before this change subscribing to a user-specific destination in STOMP
required manually appending a unique queue suffix provided in a header
with the CONNECTED frame.
This change removes the need to do that. Instead STOMP clients can
subscribe to "/user/queue/error" and can then begin to receive messages
sent to "/user/{username}/queue/error" without colliding with any other
user doing the same.
Issue: SPR-11077
This changes switches from using Jetty's WebSocketListener interface
to use Jetty's @WebSocket annotations instead. The change should be
transparent but the annnotations provide a little more controler
including handling pong frames.
This change also introduces a WebSocketMessage interface.
Issue: SPR-10877
- add WebSocketHttpHeaders
- client-side support for WebSocket extensions
- DefaultHandshakeHandler updates
- replace use of ServletAttributes in JettyRequestUpgradeStratey
- upgrade spring-web to jetty 9.0.5
This commits adds simple, overridable WebSocket Extension
filtering during the handshake phase and adds that
information in the WebSocket session.
The actual WebSocket Extension negotiation happens
within the server implementation (Glassfish, Jetty, Tomcat...),
so one can only remove requested extensions from
the list provided by the WebSocket client.
See RFC6455 Section 9.
Issue: SPR-10843
Commit 2397b21096 changed websocket
support to use GlassFish 4.0.1 nightlies, but broke support for 4.0. In
GlassFish 4.0.1, the package that TyrusEndpoint is located in changed.
This commit provides an abstract handler that does all required
GlassFish setup, but delegates to version specific upgrade handlers to
create the final TyrusEndpoint.
GlassFish 4.0 handler uses reflection to create its endpoint to prevent
dependency issues of depending on different versions of
tyrus-websocket-core and tyrus-container-servlet
After this change, annotated message handling methods configured to use
a destination prefix (e.g. "/app") no longer have to include the prefix
in their mapping. For example if a client sends a message to "/app/foo"
the annotated methods should be mapped with @MessageMapping("/foo").
Rossen Stoyanchev
Juergen Hoeller
Brian Clozel
Phillip Webb
Eric Dahl
Michael Irwin
Sam Brannen