- 25 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
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
-
- 24 10月, 2013 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
- 19 10月, 2013 3 次提交
-
-
由 Phillip Webb 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Brian Clozel 提交于
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
-
- 18 10月, 2013 4 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
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.
-
由 Rossen Stoyanchev 提交于
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.
-
由 Rossen Stoyanchev 提交于
-
- 15 10月, 2013 4 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
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.
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10890
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10955
-
- 13 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
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
-
- 11 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
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.
-
- 07 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 03 10月, 2013 2 次提交
-
-
由 Andy Wilkinson 提交于
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.
-
由 Andy Wilkinson 提交于
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.
-
- 02 10月, 2013 1 次提交
-
-
由 Andy Wilkinson 提交于
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.
-
- 01 10月, 2013 3 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10930
-
由 Andy Wilkinson 提交于
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.
-
由 Andy Wilkinson 提交于
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.
-
- 27 9月, 2013 3 次提交
-
-
由 Andy Wilkinson 提交于
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.
-
由 Andy Wilkinson 提交于
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.
-
由 Andy Wilkinson 提交于
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
-
- 09 9月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 07 9月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10888
-
- 04 9月, 2013 3 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10703
-
由 Juergen Hoeller 提交于
Issue: SPR-10880
-
由 Rossen Stoyanchev 提交于
The @Bean method now returns WebSocketHandler allowing it to be decorated via WebSocketHandlerDecorator.
-
- 03 9月, 2013 2 次提交
-
-
由 Rossen Stoyanchev 提交于
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 提交于
-
- 02 9月, 2013 3 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
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.
-
- 29 8月, 2013 4 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Issue: SRP-10868
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10605
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10835
-