-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Expose Request.matchuri() #959
Comments
FYI I will go with a reflection approach for now as it seems not great to have spark based web requests look not as good as others in tracing |
Actually I'm not clever enough to figure out how to do this without bytecode. I've considered making my own wrapper for Request, but that would be fragile to versions (unless it is expected to have no new methods added). A reflective proxy could also work, but I don't know if I can ever control the type of request (as filters in spark are callbacks, not interceptors). The failed idea here is hooking into Only other thing could be to hook into Access.changeMatch, which for bytecode is a cleaner way to accomplish the same. Please ping back if anyone knows any other options, or if someone believes that exposing this is likely to happen (even if that answer is pull requests welcome) |
I don't see why this shouldn't be included, I'll merge a PR if you create one. |
This has been merged now! |
The templated route uri looks like a decent choice for a low-cardinality grouper for metrics and traces. Seems like Request.matchuri() could be exposed (albeit nullable) to suit the job. This could be used in tools like zipkin and micrometer https://github.com/micrometer-metrics/micrometer/blob/master/micrometer-spring-legacy/src/main/java/io/micrometer/spring/web/servlet/WebMvcTags.java#L81
The text was updated successfully, but these errors were encountered: