spring-projects/spring-boot

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.

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.