Giter Club home page Giter Club logo

Comments (13)

dsyer avatar dsyer commented on March 28, 2024

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?

from spring-boot.

nebhale avatar nebhale commented on March 28, 2024

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.

from spring-boot.

dsyer avatar dsyer commented on March 28, 2024

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.

from spring-boot.

rstoyanchev avatar rstoyanchev commented on March 28, 2024

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.

from spring-boot.

philwebb avatar philwebb commented on March 28, 2024

@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?

from spring-boot.

dsyer avatar dsyer commented on March 28, 2024

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.

from spring-boot.

rstoyanchev avatar rstoyanchev commented on March 28, 2024

@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.

from spring-boot.

philwebb avatar philwebb commented on March 28, 2024

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

from spring-boot.

dsyer avatar dsyer commented on March 28, 2024

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

from spring-boot.

philwebb avatar philwebb commented on March 28, 2024

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.

from spring-boot.

filiphr avatar filiphr commented on March 28, 2024

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

from spring-boot.

wilkinsona avatar wilkinsona commented on March 28, 2024

@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?

from spring-boot.

filiphr avatar filiphr commented on March 28, 2024

@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.

from spring-boot.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.