Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite Actuator MVC adapter layer for Servlet Functional Endpoints #20290

Open
bclozel opened this issue Feb 21, 2020 · 6 comments
Open

Rewrite Actuator MVC adapter layer for Servlet Functional Endpoints #20290

bclozel opened this issue Feb 21, 2020 · 6 comments
Assignees
Labels
status: pending-design-work Needs design work before any code can be developed type: task A general task

Comments

@bclozel
Copy link
Member

bclozel commented Feb 21, 2020

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.

@bclozel bclozel added type: task A general task status: noteworthy A noteworthy issue to call out in the release notes labels Feb 21, 2020
@bclozel bclozel added this to the 2.3.0.RC1 milestone Feb 21, 2020
@bclozel bclozel self-assigned this Feb 21, 2020
@bclozel
Copy link
Member Author

bclozel commented Feb 21, 2020

A first attempt at this lead to spring-projects/spring-framework#24564 and spring-projects/spring-framework#24562.

@spencergibb
Copy link
Member

Would this affect writing web extensions to actuator? I guess I'm really asking about backwards compatibility.

@bclozel
Copy link
Member Author

bclozel commented Feb 21, 2020

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

@wilkinsona
Copy link
Member

@bclozel missing "not" in "so no, this should break backwards compatibility"?

@bclozel
Copy link
Member Author

bclozel commented Feb 25, 2020

@wilkinsona Thanks, I've edited my comment.

@bclozel
Copy link
Member Author

bclozel commented Mar 10, 2020

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.

@bclozel bclozel removed this from the 2.3.0.RC1 milestone Mar 10, 2020
@bclozel bclozel added for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged and removed status: noteworthy A noteworthy issue to call out in the release notes labels Mar 10, 2020
@wilkinsona wilkinsona removed the for: team-attention An issue we'd like other members of the team to review label Mar 11, 2020
@philwebb philwebb added status: pending-design-work Needs design work before any code can be developed and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 15, 2020
@philwebb philwebb added this to the General Backlog milestone Apr 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: pending-design-work Needs design work before any code can be developed type: task A general task
Projects
None yet
Development

No branches or pull requests

4 participants