Open BoykoAlex opened 5 years ago
Thanks for the suggestion. Unfortunately, I don't think it's possible to perform the RouterFunction -> Bean
mapping as you have described.
Actuator is dealing with a DispatcherHandler
which contains a single RouterFunctionMapping
. It contains a single RouterFunction
that isn't, itself, a bean. Typically, this composed RouterFunction
is a composition of all of the application context's RouterFunction
beans but this is an implementation detail that isn't exposed anywhere. We examine the composed function using a visitor. This provides us with access to each route (a request predicate and a handler function) but not to any information about the individual router functions.
In short, we would need some changes to be made in WebFlux.Fn to be able to support this. If you think this is worth pursuing, can you please open a Spring Framework issue and link to it here?
Somehow I missed e-mail notification with your reply... Indeed all rm functions are packed into a single one which actuator examines with a visitor... Raised: https://jira.spring.io/browse/SPR-17579
I left a comment on the corresponding JIRA that explains how to get to a RouterFunction
bean id, see https://jira.spring.io/browse/SPR-17579?focusedCommentId=164021&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-164021
@wilkinsona does Arjens suggestion help in getting to the bean id on the actuator side?
Yes, I think it does.
STS team attempts to find a spot in the source code that declares routes using functional style using the JSON data from the Actuator.
Source code example:
The JSON data from the Actuator for
/vets
route:There are two pieces of data to help matching are predicate and handler The handler data should be most helpful in matching the proper place in the source. The matching place in the source code we think should be the
route
method declaration. Based on the handler's data we cannot match theroute
method unfortunately. The lambda with magic numbers is useless in this case.It'd be great if the
details
object had something helpful to find theroute
method. Either method signature or perhaps the id of the correspondingRouterFunction
bean. Seemed like getting the bean id into the JSON is doable (ApplicationContext.getBeansOfType(RouterFunction.class, true, true)
gives an id -> bean object map, given a RouterFunction object should be easy to get the corresponding id ). Therefore the JSON would look like: