Payload parameters in @MessageMapping annotated
methods can now also be validated when annotated
with a Validation annotation (@Valid, @Validated...).
A default Validator is registered by the MessageBroker
Configurer, but it is possible to provide a list of custom
validators as well.
Issue: SPR-11185
Since the MessageHeaders constructor is makes a copy of the headers and
is protected against a null map, there is no need for the same to be
done in GenericMessage.
Issue: SPR-11268
Fix a potential race condition with GenericMessagingTemplate's inner
TemporaryReplyChannel class.
Prior to this commit the `hasReceived` member variable was read after
calling `replyLatch.countDown()`.
Issue: SPR-11206
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
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
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.
Also @SubscribeMapping is now a method-level annotation only that can
be used in combination with a type-level @MessageMapping.
This method also documents supported method arguments and return value
types on @Subscribe- and @MessageMapping methods.
Previously, StompDecoder would throw a StompConversionException when
it attempted to decode a Buffer that contained an incomplete frame.
This commit updates StompDecoder to return null when it encounters an
incomplete frame. It also resets the buffer, thereby allowing the
decode to be reattempted once more data has been received.
StompCodec's decoder function has been updated to stop attempting to
decode a Buffer when StompDecoder returns null.
Issue: SPR-11088
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.
Declare SubscribableChannel @Beans in
WebSocketMessageBrokerConfigurationSupport as
AbstractSubscribableChannel to avoid the need for casting when
registering interceptors.
Issue: SPR-11065
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
- Removed unused imports
- Organized imports
- Discontinued use of deprecated junit.framework.Assert class
- Suppressed warnings where appropriate
- Added missing generics to return type for getMappingComparator() in
SimpAnnotationMethodMessageHandler
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
Introduce base class AbstractMethodMessageHandler for
HandlerMethod-based message handling.
Add MessageCondition interface for mapping conditions to messages
with support for combining type- and method-level annotation
conditions, the ability to match conditions to messages, and also
comparing matches to select the best match.
Issue: SPR-11024
Restore pringing the payload first and headers second as it has been in
SI but also handle specifically the case where the body is a byte array
to minimize unnecessary "noise" that causes otherwise for STOMP msgs.
The STOMP UNSUBSCRIBE message does not have a destination header so
there is no obvious simple way to do a mapping and the need for it
is not clear yet.
Prior to this commit, @SubscribeEvent @UnsubscribeEvent and
@MessageMapping annotated message handling methods
could only match a strict message destination.
This commit adds a @PathVariable annotation and
updates the message matching/handling process, since
message handling methods can now match PathMatcher-like
destinations and get path variables injected in parameters.
Issue: SPR-10949
This change adds abstractions for opening and managing TCP connections
primarily for use with the STOMP broker support. As one immediate
benefit the change makes the StompBrokerRelayMessageHandler more
easy to test.
This change consolidates TCP-related logic in the StompRelaySession. As
a result the sub-class SystemStompRelaySession now contains only logic
intrinsic to the shared system session.
This change upgrades reactor to 1.0 RC1 and also removes the
reactor-based message channel in favor of the one available from
org.projectreactor:reactor-spring.
This change adds an alternative UUID generation strategy to use by
default in MessageHeaders. Instead of using SecureRandom for each
new UUID, SecureRandom is used only for the initial seed to be
provided java.util.Random. Thereafter the same Random instance is
used instead. This provides improved performance while id's are
still random but less securely so.
Includes revisions of MethodParameter and DependencyDescriptor (in particular towards a reference to the containing class). Also refines several ResolvableType method signatures.
Issue: SPR-9965
This change adds support for @Header and @Headers annotated method
arguments to spring-messaging. Also supported are arguments of type
MessageHeaders, and MessageHeaderAccessor (including sub-types of
MessageHeaderAccessort as long as they provide a wrap(Message<?>)
static factory method).
This change also renames @MessageBody to @Payload.
Issue: SPR-10985
The MessageConverter interface in spring-messaging is now explicitly
designed to support conversion of the payload of a Message<?> to and
from serialized form based on MIME type message header.
By default, the MessageHeaders.CONTENT_HEADER header is used but a
custom ContentTypeResolver can be configured to customize that.
Currently available are Jackson 2, String, and byte array converters.
A CompositeMessageConverter can be used to configure several
message converters in various places such as a messaging template.
Previously, there was no generic concept of a message that represents
a heartbeat and the STOMP-specific code used a null STOMP command to
represent a heartbeat.
This commit introduces HEARTBEAT as a new SimpMessageType. The STOMP
support has been updated to create HEARTBEAT messages to represent
heartbeats, and to use the new message type as the mechanism by which
heartbeats are identified.
Prior to this commit, the intervals at which the broker relay's system
session would send heartbeats to the STOMP broker and expect to
receive heartbeats from the STOMP broker were hard-coded at 10
seconds.
This commit makes the intervals configurable, with 10 seconds being
the default value.
Previously, when the broker relay was shut down, the TCP client was
closed and the relay sessions were left to find out about the
shutdown as a result of their TCP connections being closed. This led
to problems where an attempt could be made to use a session that was,
in fact, in the process of being shut down.
This commit updates the broker relay to explicitly close each of its
relay sessions as part of its stop processing.
As part of the broker relay being shut down explicitly close each of
its relay sessions. It does so before closing the TCP client so that
the relay sessions know that they are disconnected before their TCP
connections are closed.
The broker relay's publishing of availability events has also been
improved. Prior to this commit, availability events were published
based on the availability of any relay session. For example, this
meant that a successfully established client relay session would
result in an event being published indicating that the broker's
available even if the system relay session was yet to be established.
This commit updates the relay so that broker availability events are
only published by the system relay session. This allows application
code the use these events as an accurate indication of the
availability of the broker. Clients that are interested in the
broker's availability can find out through the use of heart beats or
through the receipt of an ERROR frame in response to an attempt to
communnicate with the broker.
Fix error in te code that handles the result of sending a heartbeat
Fix error in processing DISCONNECTED frames that closed the TCP
connection before the message was sent.
Previously, handling of a STOMP CONNECT message and sending of a
CONNECTED response was performed by StompProtocolHandler if it was
backed by SimpleBrokerMessageHandler, or left up to the real message
broker if it was backed by StompBrokerRelayMessageHandler. This
wasn't ideal as it should be StompProtocolHandler's job to simply map
messages to and from the STOMP protocol, not to do part of the
broker's job and respond directly to CONNECT.
This commit introduces a new message type, CONNECT_ACK. When it
receives a CONNECT message, SimpleBrokerMessageHandler will now
respond with a CONNECT_ACK message that StompProtocolHandler can map
into a STOMP CONNECTED message. The CONNECT_ACK message contains the
CONNECT message as a header so that StompProtocolHandler has access to
its accept-version header.
StompProtocolHandler has been simplified so that a CONNECT message
is always passed to the output channel, irrespective of whether it's
backed by a simple broker or a real broker. The handleConnect flag,
and the code that would set it correctly depending on the app's
configuration, has been removed.
Prior to this commit, a failure to send a heartbeat was ignored and a
failure to forward a message to the broker would result in an error
frame being sent but nothing more.
Following this commit, a failure to send a heartbeat to the broker
is treated as a TCP client failure. Furthermore, if the system relay
session fails to forward a message to the broker an exception is
thrown. Typically, the system relay session will be forwarding
messages on behalf of local application code, rather than a remote
WebSocket client. Throwing an exception allows the application code
to be notified of the problem directly, rather than via a broker
availability event.
Previously, when a broker heartbeat was mnissed, the STOMP connection
would be left in a semi-disconnected state such that, for example, the
read and write idle callbacks would still be active, even though
the underlying TCP connection had been nulled out.
As part of disconnecting the STOMP connection, this commit closes the
underlying TCP connection when a heartbeat's missed which cancels the
read and write idle callbacks. It also now copes with the underlying
TCP connection being null when sending a heartbeat to the broker. This
protects again a race condition between the write idle callback being
fired, such that a heartbeat needs to be sent, and the connection
being nulled out due to it being closed.
Previously, the STOMP broker relay did not support heart-beats. It sent
0,0 in the heart-beats header for its own CONNECTED message, and set the
heart-beats header to 0,0 when it was forwarding a CONNECTED from from a
client to the broker.
The broker relay now supports heart-beats for the system relay session.
It will send heart-beats at the send interval that's been negotiated
with the broker and will also expect to receive heart-beats at the
receive interval that's been negotiated with the broker. The receive
interval is multiplied by a factor of three to satisfy the STOMP spec's
suggestion of lenience and ActiveMQ 5.8.0's heart-beat behaviour (see
AMQ-4710).
The broker relay also supports heart-beats between clients and the
broker. For any given client's relay session, any heart-beats received
from the client are forwarded on to the broker and any heart-beats
received from the broker are sent back to the client.
Internally, a heart-beat is represented as a Message with a byte array
payload containing the single byte of new line ('\n') character and
'empty' headers. SubscriptionMethodReturnValueHandler has been updated
to default the message type to SimpMessageType.MESSAGE. This eases
the distinction between a heartbeat and a message that's been created
from a return value from application code.
Before this change, the StompProtocolHandler always responded to
clients with a CONNECTED frame, while the STOMP broker relay
independantly forwarded the client CONNECT to the broker and waited
for the CONNECTED frame back. That meant the relay had to buffer
client messages until it received the CONNECTED response from
the message broker.
This change ensures that clients wait for a CONNECTED frame from
the message broker. The broker relay forwards the CONNECT frame to
the broker. The broker responds with a CONNECTED frame, which the
relay then forwards to the client. As a result, a (well-written)
client will not send any messages to the relay until the connection
to the broker is fully established.
The StompProtcolHandler can now be configured whether to send CONNECTED
frame back. By default that is off. So when using the simple broker,
the StompProtocolHandler can still respond with CONNECTED frames.
The relay's handling of a connection being dropped has also been
improved. When a connection for a client relay session is dropped
an ERROR frame will be sent back to the client. If a connection is
closed as part of a DISCONNECT frame being sent, no ERROR frame
is sent back to the client. When the connection for the system relay
session is dropped, an event is published indicating that the broker
is unavailable. Reactor's TcpClient will then attempt to re-restablish
the connection.
Previously, the broker relay's TCP client used Reactor's built in
delimited codec as part of its parsing of STOMP frames. \0 was used as
the delimiter. This worked for most STOMP frames but, crucially,
not for frames with a body that contained \0: when such a frame was
received it would be truncated.
This commit adds a custom codec that parses STOMP frames more
intelligently. It honours the content-length header allowing it to
correctly parse frames with a body that contains \0. The codec largely
delegates to two new classes: StompEncoder and StompDecoder. For
consistency, code that previously used StompMessageConverter has been
reworked to use these new encoder and decoder classes.
Issue: SPR-10818
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").
Ensure configuration provided for WebSocketHandler's (eg interceptors,
or HandshakeHandler) are passed on to the SockJsService if congiured.
Better separate Servlet-specific parts of the configuration to make it
more obvious where non-Servlet alternatives could fit in.
Add more tests.
Improve WebSocket integration tests.
Previously, the negotiated version was included in the CONNECTED frame
using the accept-version header. This is incorrect. The version
header should be used.
Use a single class for the broker availability event with a boolean
that indicates whether or not the broker is available, rather than one
event for an available broker and one event for an unavailable broker.
Publish broker availability events in SimpleBrokerMessageHandler so that
it can be used as a drop-in replacement for
StompBrokerRelayMessageHandler.
Upgrade to Reactor snapshot builds to take advantage of TcpClient's
reconnect support that was added post-M1. Now, the system relay session
will try every 5 seconds to establish a connection with the broker, both
when first connecting and in the event of subsequently becoming
disconnected.
A more sophisticated reconnection policy, including back off and
failover to different brokers, is possible with the Reactor API. We may
want to enhance the relay's reconnection policy in the future.
Typically, a broken connection is identified by the failure to forward
a message to the broker. As things stand, the message id then discarded.
Any further messages that are forwarded before the connection's been
re-established are queued for forwarding once the CONNECTED frame's been
received. We may want to consider also queueing the message that failed
to send, however we would then need to consider the possibility of the
message itself being what caused the broker to close the connection
and resending it would simply cause the connection to be closed again.
Components that are using a StompBrokerRelayMessageHandler may want
to know whether or not the broker's unavailable. If they're sending
messages to the relay via an asynchronous channel there's currently
no way for them to find this out.
This commit enhances StompBrokerRelayMessageHandler to publish
application events when the broker's availability changes:
BrokerBecameAvailableEvent and BrokerBecameUnavailableEvent.
Irrespective of the number of relay sessions only a single event is
published for each change in the broker's availability.
A getCookies method is now available on ServerHttpRequest with one
ServletServerCookie implementation that wraps a Servlet cookie.
The SockJS service makes use of this to check for an existing session
cookie in the request.
Add SubProtocolHandler to encapsulate the logic for using a
sub-protocol.
A SubProtocolWebSocketHandler is also provided to
delegate to the appropriate SubProtocolHandler based on the
negotiated sub-protocol value at handshake.
StompSubProtocolHandler provides handling for STOMP messages.
Issue: SPR-10786
SI's BeanFactoryChannelResolver was BeanFactoryAware. This commit
brings Spring's BeanFactoryMessageChannelDestinationResolver in line
with the old SI class.
The resolver for /user/{username} prefixed destinations is now
more explicitly designed to store queue suffixes rather than session
id's, which is what we happen to use as queue suffixes.
This allows something other than the sessionId to be used without
having to change many places. It also enables applications to
construct destinations with user-specific queue suffixes without
making assumptions about what's used for queue suffixes. For
example a controller may construct a map with subscription destinations
and send that down to the client.
The new UserDestinationMessageHandler resolves messages with
destinations prefixed with "/user/{username}" and resolves them into a
destination to which the user is currently subscribed by appending the
user session id.
For example a destination such as "/user/john/queue/trade-confirmation"
would resolve "/trade-confirmation/i9oqdfzo" assuming "i9oqdfzo" is the
user's session id.
Remove base class for STOMP-related message handler classes
(AbstractSimpMessageHandler), polish subclasses and fix issues with
more significant updates to STOMP broker relay.
Introduce base class for SubscribableChannel implementations providing
consistent logging for all channel implementations.
Brian Clozel
Rossen Stoyanchev
Juergen Hoeller
Phillip Webb
Eric Dahl
Andy Wilkinson
Sam Brannen
Jan Machacek