Rewrite Actuator MVC adapter layer for Servlet Functional Endpoints
bclozel opened this issue · 6 comments
The Actuator MVC adapter layer is based on the MVC annotation model (especially AbstractWebMvcEndpointHandlerMapping
, which extends RequestMappingInfoHandlerMapping
). In this mode, we've got to use the annotation model in ways that aren't really ideal: programmatically registering handlers with conditions extracted from the Actuator configuration model, having very general controller handlers that mainly work because of Spring MVC flexibility.
And general and especially for #12951, we'd like to make Actuator web support independent of the main application. Without this, configuration changes in the main application will be reflected on Actuator endpoints (like the response format), which makes things inconsistent between applications. The main goal of Actuator is to provide a common, consistent model across applications, no matter what web stack they're using.
As seen in #20211, we might have found the limits of the current Actuator web adapter layer for Spring MVC. Spring Framework now ships Servlet Functional Endpoints. Unlike the annotation model, they're designed for programmatic registrations and the message converters configuration is bound to the RouterFunctionHandlerMapping
instance, whereas with the annotation model it's separate and tied to RequestMappingHandlerAdapter
.
This issue should consider whether reimplementing the MVC web adapter layer for Actuator using Servlet Functional Endpoints would be possible and solve our current issues.
A first attempt at this lead to spring-projects/spring-framework#24564 and spring-projects/spring-framework#24562.
Would this affect writing web extensions to actuator? I guess I'm really asking about backwards compatibility.
@spencergibb If you're talking about @WebEndpoint
and @WebEndpointExtension
, this is covered by a web stack agnostic infrastructure - so no, this should not break backwards compatibility.
@bclozel missing "not" in "so no, this should break backwards compatibility"?
@wilkinsona Thanks, I've edited my comment.
After building most of the integration, I noticed (and remembered) that we also ship support with @ControllerEndpoint
and @RestControllerEndpoint
. This is then not possible in its current form.