Enhance WebSockets auto-configuration to notice messaging

[nebhale]

Currently, the websockets auto-configuration simply notices the registration of WebSocketHandlers. This is a good start, but a common (possibly more common) use of WebSockets will be with some messaging on top. It'd be nice if Boot would notice the registration of beans that have been annotated with Spring Messaging annotations (e.g. @SubscribeEvent, @MessageMapping) and eliminate the boilerplate configuration.

The boilerplate configuration I'm currently having to embed looks like the following:

@Configuration
@EnableWebSocketMessageBroker
static class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/websocket");
    }

    @Override
    public void configureMessageBroker(MessageBrokerConfigurer configurer) {
        configured.setAnnotationMethodDestinationPrefixes("/app");
    }

}

As you can see it's simple configuration that would work for most users of Boot (if we were willing to be opinionated on some endpoint names, etc.). I've had a quick chat with @wilkinsona about this, so he and @rstoyanchev might be able to give you a bit more insight into how much automation can be done here.

[dsyer]

My version of the same thing (from the keynote demo) looks like this:

@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
    registry.addEndpoint("/stomp").withSockJS();
}

@Override
public void configureMessageBroker(MessageBrokerConfigurer configurer) {
    configurer.enableSimpleBroker("/topic/");
}

It's similar, but not identical (even after taking into consideration the hard-coded endpoint paths). I guess I wasn't using annotation methods or something. I'll ask Rossen to clarify.

As a side note: for your scenario we need a way to detect the usage of messaging annotations. I'm not crazy about scanning all methods on all class of all bean definitions just to find that out. Can you think of a more direct way to detect the intention to use STOMP?

[nebhale]

You implementation of registerStompEndpoints() and mine are effectively the same. I've chosen a different endpoint name (I'm not wedded to it) and not added SockJS support. I've been informed that adding it at all times doesn't cause an issue so the auto-configuration could have that.

The use of enableSimpleBroker() does indeed bypass the endpoints; in essence it doesn't route to your app. So, maybe my configured.setAnnotationMethodDestinationPrefixes("/app") and your configurer.enableSimpleBroker("/topic/"). The Portfolio sample maps both /queue/ and /topic/ so maybe all three are candidates for defaults.

As to the scanning, doesn't Spring already index all of that information when it scans for other things? I might be making that up though.

[dsyer]

There appear to be 2 design issues to sort out before we can move ahead on this. How to: 1) detect that the user wants to enable a webSocket MessageBroker; 2) decide whether to add a broker relay and what to do with the simple broker. With 2), maybe the user wants us to enable a broker relay for production use, but use a simple broker with the same routing keys if in development. Spring profiles seem like an obvious way to approach that, but Spring Boot does not currently bless any special profile names, and I prefer not to create a precedent. Also maybe that's not what the user wants. 1) is also tricky, even if Spring made bean definition class metadata searchable (it doesn't as far as I know), because it isn't obvious that a webSocket MessageBroker is the intended recipient of @MessageMapping or @SubscribeEvent. On the other hand, I suppose, arguably the developer who adds a @MessageMapping is happy to get a message from any source, so maybe it would be OK to always setAnnotationMethodDestinationPrefixes. It's probably best to throw that open for discussion.

[rstoyanchev]

I'd like to revive this thread. I think the current situation with the WebSocket auto configuration is far from ideal and can lead to confusing situations (see for example https://jira.springsource.org/browse/SPR-11498).

WebSocketAutoConfiguration looks for the presence of WebSocketHandler.class on the classpath, i.e. spring-websocket. However, the presence of spring-websocket is more likely to suggest the use of @Controller + @MessageMapping methods. After all that is the way we recommend to create WebSocket style applications. Based on that I think WebSocketAutoConfiguration will kick in in cases where the intent was not to use raw WebSocket.

I actually don't find that `WebSocketAutoConfiguration brings enough value to justify its existence. Most applications should configure the SockJS task scheduler, which requires WebSocketConfigurer, which turns off the auto configuration. Or if not using SockJS, then you go down the same path. I don't see the point of auto-configuration then.

I think the WebSocketMessageBrokerAutoConfiguration discussed here is going to provide much more value. As far as (1) when to enable it.. I would say the presence of both spring-websocket and spring-messaging should be a good enough reason. As for (2) simple broker or broker relay, profiles, etc .. I would say configure a simple broker and leave it to applications to implement a WebSocketMessageBrokerConfigurer to customize it. This is no different than the WebMvcAutoConfiguration where we let users have WebMvcConfigurer along with auto configuration, and back off at the presence of WebMvcConfigurationSupport.

Potentially we could consider the presence of reactor-tcp (in addition to spring-websocket and spring-messaging) as an indicator that the broker relay is preferred but I don't see that as very useful since the broker relay properties should be customized in any case.

[philwebb]

@dsyer We should probably make a call on this before 1.0. If the current WebSocketAutoConfiguration doesn't provide enough value then perhaps we should drop it an work on a WebSocketMessageBrokerAutoConfiguration for 1.1?

[dsyer]

I don't think we should drop the WebSocketAutoConfiguration - when I read the javadocs it makes total sense to me, and I remember how confusing it was to get started with vanilla Spring Websockets.

I think it makes sense if we simply adjust the @Conditionals that trigger the autoconfig (e.g. as @rstoyanchev pointed out it only helps if there actually are some WebSocketHandlers in the application already). The SockJS task scheduler could also be broken out into a separate user-configurable feature independent of the handlers.

[rstoyanchev]

@dsyer your experience was from before RC1 when the samples and documentation were still evolving. I recall spring-websocket-test had the Spring WebSocketHandler and vanilla JSR-356 examples together making it harder to understand. If you look at the reference it's as simple as copy and paste, is it not? Furthermore your experience today would likely be based on the WebSocket GS guide.

Let's suppose the WebSocketAutoConfiguration remains. If I want to turn off SockJS, I have to turn off the auto configuration. If I want to configure the SockJS task scheduler, which I should, I have to turn off the auto configuration. Explain the value then of the auto configuration if I have to turn it off no matter what.

[philwebb]

@dsyer Should we mark this as fixed, target to 1.0.0.RELEASE and open another issue for whatever tasks remain?

[dsyer]

I don't feel like this one really is fixed. Leave it open?

[philwebb]

We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.

[filiphr]

This has been closed due to inactivity. However, we are currently using websockets with STOMP a lot and have build our own auto configuration with it. Will the Spring Boot team be interested in having such auto configuration? If yes I can prepare something and provide a PR.

There is also an example of Spring Boot and Websockets at https://github.com/salmar/spring-websocket-chat which goes even further and provides some nice actuator endpoints

[wilkinsona]

@filiphr We still haven't seen too much demand, but it would certainly be interesting to see what you've got in terms of auto-configuration. Is it somewhere that we could look at it without you having to go to too much effort?

[filiphr]

@wilkinsona the auto-configuration is currently in a closed repository. However, I am going to find some time and extract it out and publish it so you can have a look at it.