@@ -1929,9 +1929,10 @@ will typically notice the broker is not responding within 10 seconds. Clients ne
1929
1929
implement their own reconnect logic.
1930
1930
====
1931
1931
1932
- Furthermore, an application can directly intercept every incoming and outgoing message by
1933
- registering a `ChannelInterceptor` on the respective message channel. For example
1934
- to intercept inbound messages:
1932
+ The above events reflect points in the lifecycle of a STOMP connection. They're not meant
1933
+ to provide notification for every message sent from the client. Instead an application
1934
+ can register a `ChannelInterceptor` to intercept every incoming and outgoing STOMP message.
1935
+ For example to intercept inbound messages:
1935
1936
1936
1937
[source,java,indent=0]
1937
1938
[subs="verbatim,quotes"]
@@ -1947,8 +1948,7 @@ to intercept inbound messages:
1947
1948
}
1948
1949
----
1949
1950
1950
- A custom `ChannelInterceptor` can extend the empty method base class
1951
- `ChannelInterceptorAdapter` and use `StompHeaderAccessor` or `SimpMessageHeaderAccessor`
1951
+ A custom `ChannelInterceptor` can use `StompHeaderAccessor` or `SimpMessageHeaderAccessor`
1952
1952
to access information about the message.
1953
1953
1954
1954
[source,java,indent=0]
@@ -1966,6 +1966,12 @@ to access information about the message.
1966
1966
}
1967
1967
----
1968
1968
1969
+ Note that just like with the `SesionDisconnectEvent` above, a DISCONNECT message
1970
+ may have been sent from the client, or it may also be automatically generated when
1971
+ the WebSocket session is closed. In some cases an interceptor may intercept this
1972
+ message more than once per session. Components should be idempotent with regard to
1973
+ multiple disconnect events.
1974
+
1969
1975
1970
1976
1971
1977
[[websocket-stomp-client]]
0 commit comments