Affects: 5.0.6.RELEASE

Aim: Support multiple SimpMessagingTemplate beans inside the same application using WebSockets.

My use case: Configuring WebSockets with an external relay to a message broker. Following the configuration example in the Reference Manual helps in setting up a basic functionality.

Problem: AbstractMessageBrokerConfiguration#brokerMessagingTemplate registers a SimpMessagingTemplate class by default. Overriding the @Bean method does not help.

Expected: There should be a way to bootstrap bean creation using a qualifier. This is required since if another module tries to create its own WebSocket configuration, this will either override or result in a creation error.

Comment From: sbrannen

@rstoyanchev, can you please take a look at this?

Comment From: rstoyanchev

This is required since if another module tries to create its own WebSocket configuration, this will either override or result in a creation error.

By that you mean there is another AbstractMessageBrokerConfiguration in the same application? That's not really meant to be. There are lots of other beans that would be duplicated aside from the "brokerMessagingTemplate" bean. There should only be of those @Configuration files per application. I'm probably missing something about what you're saying.

Comment From: adityarar

Thanks for clarifying. So, the thing is we have an issue regarding multiple SimpMessagingTemplate registered in spring context. A part of the application tries to inject the template by 'type'. And fails since it finds 2 beans of the same type.

So, I was working on creating my websocket-config outside spring context, but that is not possible. So should we fix this injection or look for something else?

Also, just for clarity, if in future someone creates there own websocket config, even though the broker template gets overriden, rest of the functionality(like stomp relay, endpoints) will not get overriden right?

Comment From: TLN2

I just found this issue, which is very similar to one that I created two days ago (#22535). Sorry for the overlap.

I also consider it a totally legitimate wish to have several distinct brokers and thus several instances of SimpMessagingTemplate in one application. Otherwise I must be missing something about the current architecture.

For instance take this short sample configuration as a starting point: https://github.com/spring-projects/spring-framework/blob/master/spring-websocket/src/test/resources/org/springframework/web/socket/config/websocket-config-broker-relay.xml

Even though it may allow me to add more endpoints and more STOMP broker relays inside the existing <websocket:message-broker> tag, this may still not be what is desirable:

Assume we register two endpoints /public and /internal, for public services and internal communication, respectively. I haven't tested it, but the current architecture seems to mean that everyone who has access to the public endpoint can subscribe to topics that are only meant to be distributed through the internal endpoint.

Or let's say we have to work with several different RabbitMQ instances for some reason, and they use same prefixes (e.g. "/topic"). Is this possible with the current design, I mean can we clearly distinguish how to relay messages that are meant for either of the two?

The issue that adityarar seems to point out if I'm getting him correctly goes on top: If there are several nested application contexts or you want to combine separate independent configuration files in one context, things either break unexpectedly, or behavior is hard to predict.

Comment From: rstoyanchev

I think the use cases between here and #22535 sound related but are different.

The request here is for multiple modules within the same application to have their own independent STOMP/WebSocket infrastructure. As there is only one WebSocket server it's not clear how that would be shared between the modules which are otherwise supposed to be independent from each other.

The request under #22535 is to support relaying to and from multiple brokers in the backend with destination prefixes used to differentiate which message is for which broker. This scenario seems more feasible. We'd probably enhance StompBrokerRelayMessageHandler to support connections to multiple brokers and choose among them based on destination prefix mappings. A single SimpMessagingTemplate might even be sufficient since it's the destinations that determine where a message should go.

I am closing this issue as support for multiple independent STOMP/WebSocket sets of infrastructure is not feasible.