Почему функциональность STOMP в Spring-Websocket зависит от Spring MVC?

Question

В настоящее время я пытаюсь использовать STOMP с веб-сокетами, используя webflux. Для того, чтобы отправить сообщение в тему STOMP, мне нужно использовать SimpMessagingTemplate, что обеспечивается автоматической настройкой весенней загрузки при добавлении @EnableWebSocketMessageBroker

Но проблема в том, что @EnableWebSocketMessageBroker косвенно ожидает, что у меня будет spring-mvc библиотека в classpath

@EnableWebSocketMessageBroker @Import s DelegatingWebSocketMessageBrokerConfiguration, который расширяет WebSocketMessageBrokerConfigurationSupport & WebSocketMessageBrokerConfigurationSupport#stompWebSocketHandlerMapping метод ожидает, что класс HandlerMapping будет возвращен

Мой вопрос

1. Как интегрировать STOMP с webflux без webmvc
2. Почему автоконфигурация заставляет нас иметь mvc в classpath (и потенциально конфликтовать с webflux)

Answer 1

Если вы выполняете поиск по запросу «stomp webflux» в Google, самым первым (для меня) попаданием будет проблема в системе отслеживания проблем Spring Boot , в которой кратко описывается, почему она не поддерживается:

Существует общее намерение предоставить поддержку обмена сообщениями более высокого уровня, согласованную с WebFlux, но конкретной целевой версии еще нет. Обратите внимание, что мы исследуем gRPC и поддержка RSocket, которые относятся к одной общей категории.

В строке 5.2 запущена поддержка RSocket, так что вы можете посмотреть на это.