Provide an API for introspection of handler mappings [SPR-15934]

[spring-projects-issues]

Andy Wilkinson opened SPR-15934 and commented

Spring Boot provides an Actuator endpoint that aims to list all Spring MVC (or WebFlux) mappings. It's current implementation is rather haphazard in terms of what it does and does not list, and the format in which mappings are listed. Please see some of the comments and concerns raised in spring-projects/spring-boot#9979 for more details.

Would it be possible for Spring MVC and WebFlux to provide a supported API for introspecting DispatcherServlet and DispatcherHandler handler mappings respectively? I think Boot's current implementation could, in some ways, be improved by reflectively accessing DispatcherServlet.handlerMappings and burrowing down from there but that would still be something of a hack.

---

Affects: 5.0 RC3

Reference URL: spring-projects/spring-boot#9979

Issue Links:

• Provide an API for introspection of a dispatcher handler's handler mappings [SPR-15935] #20489 Provide an API for introspection of a dispatcher handler's handler mappings ("is duplicated by")
• DispatcherHandler no longer orders HandlerMapping beans [SPR-15991] #20541 DispatcherHandler no longer orders HandlerMapping beans

Referenced from: commits 41b53de, 9ff4c0b, 819ca0d, c28a635

[spring-projects-issues]

Rossen Stoyanchev commented

Typically there should be no need to open separate tickets for Spring MVC and WebFlux. The default assumption for us is to to consider the impact to both regardless of which side the ticket came from. So I'm consolidating this with #20489 which would duplicate the same discussion.

[spring-projects-issues]

Andy Wilkinson commented

Noted. Thanks, Rossen.

[spring-projects-issues]

Rossen Stoyanchev commented

What exactly would you like to see?

On the WebFlux side DispatcherHandler is already a bean and we could easily add a method that returns the HandlerMapping beans it detected. If we did something similar for Spring MVC, I suspect Boot would be able to access such a property on the DispathcerServlet?

Beyond access to HandlerMapping's the actual mapping metadata is different between SimpleUrlHandlerMapping (just patterns) and @RequestMapping controller methods. We would have to return some String representation or otherwise you might be better off anyway accessing each based on its actual type?

Also can you point me to the Actuator code that does this? I don't understand why it doesn't detect Spring Data REST mappings, nor why is it hard to have the mappings sorted according to HandlerMapping order, and/or stored in something other than a map.

[spring-projects-issues]

Andy Wilkinson commented

Accessors on both DispatcherServlet and DispatcherHandler would, I think, be a big step in the right direction.

We would have to return some String representation or otherwise you might be better off anyway accessing each based on its actual type?

The current implementation relies on the toString of the mappings which does seem to provide a reasonable representation while not really using the method as intended. I think I would be more comfortable with either a method that's specifically for this purpose, or with accessing the information based on the actual type of each mapping. I could envisage the latter allowing us to provide richer information about, for example, request-mapped methods where we could break down the various components of the mapping info.

Also can you point me to the Actuator code that does this? I don't understand why it doesn't detect Spring Data REST mappings, nor why is it hard to have the mappings sorted according to HandlerMapping order, and/or stored in something other than a map.

The current code is here: https://github.com/spring-projects/spring-boot/blob/1.5.x/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/endpoint/RequestMappingEndpoint.java.

IIRC, the Data REST mappings aren't detected because its handler mapping is a black box. I should open a separate DATAREST issue for that.

There's nothing particularly hard about sorting the mappings, but we'd have to duplicate the logic in DispatcherServlet that finds the mappings and sorts them. I'd prefer not to have to do either of these things and to be able to build on what the dispatcher servlet's already done instead. As things stand, you could have a handler mapping bean in the context and a dispatcher servlet that isn't actually using it (in the unlikely event of detect all mappings being disabled).

We will move from returning a map of the mappings. Given that the ordering is important a list would be more appropriate. We'll do that irrespective of the outcome of this issue.

[spring-projects-issues]

Rossen Stoyanchev commented

Sorry for the slow response. I've added getters on both sides. What else would you like to see?

[spring-projects-issues]

Andy Wilkinson commented

Thanks, Rossen. Those getters go a pretty long way to giving us what we need, particularly if I consider different mappings by their concrete type (there's lots of useful information in RequestMappingInfo for example). One thing that I'd still like to see is a getter for the RouterFunction s in a RouterFunctionMapping. That, combined with Arjen's changes in #20268, will, I believe, allow introspection of the mappings to give us a pretty complete view of things.

[spring-projects-issues]

Rossen Stoyanchev commented

I've added a getter for RouterFunction. Note that it will return null if called before initialized when in the mode of detecting. I've done the same for both getHandlerMapping methods to align the behavior and to provide a clear signal when not yet configured.