-
Notifications
You must be signed in to change notification settings - Fork 41.4k
Description
The mappings endpoint is currently described as returning "a collated list of all @RequestMapping
paths". It actually returns more than that as it introspects any AbstractUrlHandlerMapping
and AbstractHandlerMethodMapping
instances, not just those that are associated with @RequestMapping
. However, there are some mappings that it doesn't currently return such as those configured by Spring Data REST.
Beyond the accuracy of the description, the content of the response is a little haphazard. It currently looks like this:
{
"/**": {
"bean": "resourceHandlerMapping"
},
"/**/favicon.ico": {
"bean": "faviconHandlerMapping"
},
"/webjars/**": {
"bean": "resourceHandlerMapping"
},
"{[/application/auditevents],methods=[GET],produces=[application/vnd.spring-boot.actuator.v2+json || application/json]}": {
"bean": "webEndpointServletHandlerMapping",
"method": "public java.lang.Object org.springframework.boot.endpoint.web.mvc.WebEndpointServletHandlerMapping$OperationHandler.handle(javax.servlet.http.HttpServletRequest,java.util.Map<java.lang.String, java.lang.String>)"
},
"{[/application/autoconfig],methods=[GET],produces=[application/vnd.spring-boot.actuator.v2+json || application/json]}": {
"bean": "webEndpointServletHandlerMapping",
"method": "public java.lang.Object org.springframework.boot.endpoint.web.mvc.WebEndpointServletHandlerMapping$OperationHandler.handle(javax.servlet.http.HttpServletRequest,java.util.Map<java.lang.String, java.lang.String>)"
},
"{[/application/beans],methods=[GET],produces=[application/vnd.spring-boot.actuator.v2+json || application/json]}": {
"bean": "webEndpointServletHandlerMapping",
"method": "public java.lang.Object org.springframework.boot.endpoint.web.mvc.WebEndpointServletHandlerMapping$OperationHandler.handle(javax.servlet.http.HttpServletRequest,java.util.Map<java.lang.String, java.lang.String>)"
}
// …
}
The keys in the map are just the toString()
of the mapping object which can, essentially, be anything. As such, there's no guarantee of the format of the key. There's also, as far as I know, no guarantee that the keys will be unique across everything that's introspected so entries in the map may clash. Lastly, handler mappings are ordered and this ordering is lost by using a map.
We also need to figure out what, if anything, we want to do for WebFlux and Jersey. Perhaps they should be completely separate endpoints? However, if you're using a combination of MVC and Jersey it might be nice to have all mappings available from a single source.
Activity
wilkinsona commentedon Sep 7, 2017
I've opened some Framework issues that all relate to this:
wilkinsona commentedon Sep 27, 2017
Let's try and also include information about Filters and Servlets too (previously tracked by #2178).
wilkinsona commentedon Nov 1, 2017
Here's an example of a what the response might look like for an app using Spring MVC and Spring Data REST:
And here's an example for a WebFlux application:
A few notes about the example responses:
dispatcherServlets
anddispatcherHandlers
are as there may be more than oneDispatcherServlet
orDispatcherHandler
bean in the application context.dispatcherServlets
anddispatcherHandlers
maps are the names of the beans.dispatcherServlets
anddispatcherHandlers
maps are arrays of the known handlers. The order of the array reflects the order of the handlers in the dispatcher.dispatcherServlets
,dispatcherHandlers
,servlets
,servletFilters
) are named such that they are unique even when a client might be dealing with a mixture of servlet and reactive web applications.WebFilter
s used by WebFlux but that doesn't appear to be possible (at the moment at least) without resorting to reflective hacks.kaleev commentedon Nov 2, 2017
Mapping endpoint's output contains endpoints entries (e.g beans, health) when management port is equal to application port, and it doesn’t contain them when management port differs from application port.
It seems like a bug. So it should be possible to distinguish management request mappings and application request mappings in json output, since IDEA as well as STS need to build correct URLs for entries from the output in order to get an ability to navigate to them.
I suppose top-level 'context' keys would be enough.
wilkinsona commentedon Nov 2, 2017
Thank you, @kaleev. Given that the change proposed here is going to be a breaking change to the JSON's structure, and fixing the problem you've described would also require a breaking change, doing both at the same time makes a lot of sense. I'll see what we can do.
wilkinsona commentedon Nov 2, 2017
The problem with the mappings not being visible when there's a context hierarchy (as there is when the management port is set) is a specific case of the problem tracked by #5312.
wilkinsona commentedon Nov 2, 2017
There's a problem with the proposed implementation when the management port has been configured. If a request to the mappings endpoint is made before the application's dispatcher servlet has handled any request, its handler mappings will be
null
as they are only initialized on first request by default. I've asked @rstoyanchev if there's anything that could be done in the Framework to remove this restriction.7 remaining items
wilkinsona commentedon Jan 16, 2018
The response structure has changed to align with the recent changes for better handling of context hierarchies. Here's an example of the updated structure:
contexts
is a new top-level entry. This map contains an entry for each application context, keyed by id, that's known to the endpoint. Each entry for a specific context has two keys:parentId
andmappings
.parentId
is the id of the parent context, if any.mappings
is a map of the context's mappings with entries that use the same 4 possible keys as described above (dispatcherServlets
,dispatcherHandlers
,servlets
,servletFilters
).wilkinsona commentedon Jan 22, 2018
The code would benefit from being in a mappings-specific package rather than the more general-purpose
actuate.web
package that it's currently in.5 remaining items