The @Header annotation in spring-messaging now resolves values from the
nested "nativeHeaders" map as well as top-level header map values.
In case of ambiguity (a value that exists in both), the top-level map
value is used and a warning message is printed. This is unlikly in most
cases but can be resolved by prefixing the header value with
"nativeHeadres.myHeader".
Issue: SPR-11326
DefaultUserDestinationResolver now uses the session id of
SUBSCRIBE/UNSUBSCRIBE messages rather than looking up all session id's
associated with a user.
Issue: SPR-11325
Before this change DefaultUserDestinationResolver provided a separate
destination prefix property for identifying "user" destinations in
subscription requests as opposed to in sent messages. Such a separate
property should not be needed.
Issue: SPR-11263
Configurers and BeanDefinitionParsers should use
OptionalValidatorFactoryBean instead of
LocalValidatorFactoryBean.
The Optional implementation catches and logs setup
exceptions, useful when a validation API is present on
the classpath but not the actual implementation.
Issue: SPR-11272
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
Rossen Stoyanchev
Sam Brannen
Brian Clozel
Juergen Hoeller
Phillip Webb
Eric Dahl
Andy Wilkinson