Был ли кто-нибудь успешным или нуждался в замене кода, который в конечном итоге управляет подписками? - что, по моему пониманию, делает DefaultSubscriptionRegistry?
Нужно ли использовать AbstractMessageBrokerConfiguration для реализации нашего собственного SubscriptionRegistry, или есть менее навязчивая альтернатива?
Я нахожусь в ситуации, когда мне нужно иметь более персонализированный SubscriptionRegistry. В частности, мне нужно, чтобы остальная часть моего приложения знала, когда пользователь подписывается на определенный пункт назначения. В настоящее время я использую события ApplicationContext (например, SessionSubscribeEvent, SessionUnsubscribeEvent, ...), чтобы сообщить мне об этом. Это переросло в сценарий, в котором я в основном управляю подписками на сеансы параллельно с DefaultSubscriptionRegistry. Это можно было бы преодолеть, если бы только я мог внести довольно сдержанное изменение в DefaultSubscriptionRegistry [ввести наблюдаемое там].
Софар, я не смог этого сделать. Я считаю, что моя проблема в том, что метод getBrokerRegistry() в классе AbstractMessageBrokerConfiguration является окончательным. Если бы это было не так, я думаю, я мог бы перезаписать его, чтобы вернуть пользовательский MessageBrokerRegistry. Этот пользовательский MessageBrokerRegistry просто перезапишет метод enableSimpleBroker. В конце концов, я смогу схватить SimpleBrokerMessageHandler и вызвать его метод public setSubscriptionRegistry(SubscriptionRegistry myCustomSubscriptionRegistry).
Я собираюсь просто разветвить AbstractMessageBrokerConfiguration, скопировать весь его контент, но удалив ключевое слово final. Есть ли лучший способ добиться этого?
Первоначально опубликовано в разделе вопросов: https://github.com/rstoyanchev/spring-websocket-portfolio/issues/78. Решил проверить, сталкивался ли кто-нибудь из вас с такой же проблемой.
Также я использую версию 5.1.11.RELEASE для обоих артефактов spring-messaging и spring-websocket.
.