When users create a @WebEndpoint
, they can't push content to their clients using SSE or WebSockets and having this functionality could be useful in certain custom use-cases.
This could be useful for existing endpoints as well like LogFileWebEndpoint
or the new /traces
endpoint in Spring Cloud Sleuth: https://github.com/spring-cloud/spring-cloud-sleuth/pull/1964
Comment From: jonatan-ivanov
fyi: in the case of Sleuth we would like to push binary data that as far as I know is not supported by SSE. We would like to support OpenTelemetry and their binary format: OTLP (protobuf).
Comment From: wilkinsona
I'm not sure that we should try to add SSE or WebSocket support to Actuator. It would require us to implement a web-stack-agnostic abstraction for each and then provide Jersey, Spring MVC, and Spring WebFlux-based implementations of those two abstractions. This feels to me like something that either perhaps shouldn't be an Actuator endpoint or should be implemented as a @ControllerEndpoint
and only support MVC and WebFlux. Let's see what the rest of the team thinks.
Comment From: philwebb
It feels like it might be a hard abstraction for us to develop so I think at least starting with a @ControllerEndpoint
and only supporting MVC / WebFlux initially would be a good call. There's also JerseyEndpointResourceFactory
so perhaps Jesey can also eventually be supported in Sleuth.
As far as the LogFileWebEndpoint
goes, I think it's better for this problem to be solved at the platform level. I'd rather we just System.out
the logs and the platform deals with them however it sees fit. Live logging updates sound nice, but if it's solved at the platform level then all apps get it and the UI can be consistent.
Comment From: philwebb
We discussed this issue again on our team call last week. Unfortunately we don't feel like trying to support SSE or Websockets with our current abstraction is viable. A redesign is likely to be quite time consuming and we're not sure it's worth the investment at this point in time. We feel like our focus needs to be on other issues that have a higher priority for Spring Boot 3.0.
Sorry about that. Hopefully you can get somewhere using the @ControllerEndpoint
abstraction.