|
|
|
@ -1214,22 +1214,17 @@ methods as described next. |
|
|
|
[[websocket-stomp-message-mapping]] |
|
|
|
[[websocket-stomp-message-mapping]] |
|
|
|
==== `@MessageMapping` |
|
|
|
==== `@MessageMapping` |
|
|
|
|
|
|
|
|
|
|
|
The `@MessageMapping` annotation can be used on methods to route messages based on their |
|
|
|
`@MessageMapping` can be used to annotate methods to route messages based on their |
|
|
|
destination. It is supported at the method level as well as at the type level. At type |
|
|
|
destination. It is supported at the method level as well as at the type level. At type |
|
|
|
level `@MessageMapping` is used to express shared mappings across all methods in a |
|
|
|
level `@MessageMapping` is used to express shared mappings across all methods in a |
|
|
|
controller. |
|
|
|
controller. |
|
|
|
|
|
|
|
|
|
|
|
By default destination mappings are expected to be Ant-style, path patterns, e.g. "/foo*", |
|
|
|
The mapping values are Ant-style path patterns by default, e.g. "/foo*", "/foo/**" |
|
|
|
"/foo/**". The patterns include support for template variables, e.g. "/foo/{id}", that can |
|
|
|
including support for template variables, e.g. "/foo/{id}", that can be referenced via |
|
|
|
be referenced with `@DestinationVariable` method arguments. |
|
|
|
`@DestinationVariable` method arguments. Applications can also switch to a dot-separated |
|
|
|
|
|
|
|
destination convention for mappings, as explained in <<websocket-stomp-destination-separator>>. |
|
|
|
|
|
|
|
|
|
|
|
[TIP] |
|
|
|
*Supported Method Arguments* |
|
|
|
==== |
|
|
|
|
|
|
|
Applications can choose to switch to a dot-separated destination convention. |
|
|
|
|
|
|
|
See <<websocket-stomp-destination-separator>>. |
|
|
|
|
|
|
|
==== |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`@MessageMapping` methods can have flexible signatures with the following arguments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[cols="1,2", options="header"] |
|
|
|
[cols="1,2", options="header"] |
|
|
|
|=== |
|
|
|
|=== |
|
|
|
@ -1271,47 +1266,52 @@ Values will be converted to the declared method argument type as necessary. |
|
|
|
|
|
|
|
|
|
|
|
|=== |
|
|
|
|=== |
|
|
|
|
|
|
|
|
|
|
|
When an `@MessageMapping` method returns a value, by default the value is serialized to |
|
|
|
*Return Values* |
|
|
|
a payload through a configured `MessageConverter`, and then sent as a `Message` to the |
|
|
|
|
|
|
|
`"brokerChannel"` from where it is broadcast to subscribers. The destination of the |
|
|
|
By default, the return value from an `@MessageMapping` method is serialized to a payload |
|
|
|
outbound message is the same as that of the inbound message but prefixed with `"/topic"`. |
|
|
|
through a matching `MessageConverter`, and sent as a `Message` to the `"brokerChannel"` |
|
|
|
|
|
|
|
from where it is broadcast to subscribers. The destination of the outbound message is the |
|
|
|
|
|
|
|
same as that of the inbound message but prefixed with `"/topic"`. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The `@SendTo` and `@SendToUser` annotations can be used to customize the destination of |
|
|
|
|
|
|
|
the output message. `@SendTo` is used to simply customize target destination, or to |
|
|
|
|
|
|
|
specify multiple destinations. `@SendToUser` is used to direct the output message only |
|
|
|
|
|
|
|
to the user associated with the input message, see <<websocket-stomp-user-destination>>. |
|
|
|
|
|
|
|
|
|
|
|
You can use the `@SendTo` method annotation to customize the destination to send |
|
|
|
`@SendTo` and `@SendToUser` may both be used at the same time on the same method, and both |
|
|
|
the payload to. `@SendTo` can also be used at the class level to share a default target |
|
|
|
are supported at the class level in which case they act as a default for methods in the |
|
|
|
destination to send messages to. `@SendToUser` is an variant for sending messages only to |
|
|
|
class. However keep in mind that _any_ method-level `@SendTo` or `@SendToUser` annotations |
|
|
|
the user associated with a message. See <<websocket-stomp-user-destination>> for details. |
|
|
|
override _any_ such annotations at the class level. |
|
|
|
|
|
|
|
|
|
|
|
The return value from an `@MessageMapping` method may be wrapped with `ListenableFuture`, |
|
|
|
Messages may be handled asynchronously and a `@MessageMapping` method may return |
|
|
|
`CompletableFuture`, or `CompletionStage` in order to produce the payload asynchronously. |
|
|
|
`ListenableFuture`, `CompletableFuture`, or `CompletionStage`. |
|
|
|
|
|
|
|
|
|
|
|
As an alternative to returning a payload from an `@MessageMapping` method you can also |
|
|
|
Note that `@SendTo` and `@SendToUser` are merely a convenience that amounts to using the |
|
|
|
send messages using the `SimpMessagingTemplate`, which is also how return values are |
|
|
|
`SimpMessagingTemplate` to send messages. If necessary, for more advanced scenarios, |
|
|
|
handled under the covers. See <<websocket-stomp-handle-send>>. |
|
|
|
`@MessageMapping` methods can fall back on using the `SimpMessagingTemplate` directly. |
|
|
|
|
|
|
|
This can be done instead of, or possibly in addition to returning a value. |
|
|
|
|
|
|
|
See <<websocket-stomp-handle-send>>. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[[websocket-stomp-subscribe-mapping]] |
|
|
|
[[websocket-stomp-subscribe-mapping]] |
|
|
|
==== `@SubscribeMapping` |
|
|
|
==== `@SubscribeMapping` |
|
|
|
|
|
|
|
|
|
|
|
The `@SubscribeMapping` annotation is used in combination with `@MessageMapping` in order |
|
|
|
`@SubscribeMapping` is used together with `@MessageMapping` to narrow the mapping to |
|
|
|
to narrow the mapping to subscription messages. In such scenarios, the `@MessageMapping` |
|
|
|
subscription messages. In this scenario `@MessageMapping` expresses message destination |
|
|
|
annotation specifies the destination while `@SubscribeMapping` indicates interest in |
|
|
|
mappings for routing purposes, which can be done at the class or at the method level, |
|
|
|
subscription messages only. |
|
|
|
while `@SubscribeMapping` narrows the mapping to subscription messages only. |
|
|
|
|
|
|
|
|
|
|
|
An `@SubscribeMapping` method is generally no different from any `@MessageMapping` |
|
|
|
Methods with `@MessageMapping` and `@SubscribeMapping` support the same |
|
|
|
method with respect to mapping and input arguments. For example you can combine it with a |
|
|
|
<<websocket-stomp-message-mapping,method arguments>> as methods annotated only with |
|
|
|
type-level `@MessageMapping` to express a shared destination prefix, and you can use the |
|
|
|
`@MessageMapping` do. However for the return value, in the absence of `@SendTo` and |
|
|
|
same <<websocket-stomp-message-mapping,method arguments>> as any @MessageMapping` method. |
|
|
|
`@SendToUser`, a message is sent directly as a reply to the subscription, via the |
|
|
|
|
|
|
|
"clientOutboundChannel" channel. Effectively the subscription is used as a one-time, |
|
|
|
The key difference with `@SubscribeMapping` is that the return value of the method is |
|
|
|
request-reply message exchange with the subscription never stored. This is useful for |
|
|
|
serialized as a payload and sent, not to the "brokerChannel" but to the |
|
|
|
loading data on startup and for initializing a front-end UI. |
|
|
|
"clientOutboundChannel", effectively replying directly to the client rather than |
|
|
|
|
|
|
|
broadcasting through the broker. This is useful for implementing one-off, request-reply |
|
|
|
If an `@SubscribeMapping` method is annotated with `@SendTo` and `@SendToUser` the return |
|
|
|
message exchanges, and never holding on to the subscription. A common scenario for this |
|
|
|
value is sent to the `"brokerChannel"` as usual, sending a message subscribers of the |
|
|
|
pattern is application initialization when data must be loaded and presented. |
|
|
|
specified destination(s). |
|
|
|
|
|
|
|
|
|
|
|
A `@SubscribeMapping` method can also be annotated with `@SendTo` in which case the |
|
|
|
|
|
|
|
return value is sent to the `"brokerChannel"` with the explicitly specified target |
|
|
|
|
|
|
|
destination. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[[websocket-stomp-exception-handler]] |
|
|
|
[[websocket-stomp-exception-handler]] |
|
|
|
|