Investigate Jetty- and Tomcat-specific equivalents of ServerHttpObservationFilter for use with embedded web servers #48472
Description
I suspect this will be closed as a duplicate, but I've feel like I've read a hundred different, yet similar issues and the error handling documentation doesn't make the issue any clearer. Part of this is because of the search results being polluted by old Sleuth related information, but in this case I'm using Spring Boot 3.5.8 with Micrometer 1.6.0.
I've noticed in certain flows, such as an exception being raised and error logged by the default JWT Decoder (In Spring Security's OAuth2 default configuration, NimbusJwtDecoder) or the initial FilterChainProxy debug log when a secured endpoint is called, the Trace ID and Span ID are missing from logs despite the logger being configured to show them. In the JWT decoder example, if I replace the default decoder with a simple wrapper that manually logs a warning level message, the trace and span information will be included in that log, but the eventual error level log that will happen once it reaches the servlet will not have that information.
My consternation with this is that typically users of this framework are going to want to raise an Exception and have that be handled by the framework -- irrespective of if it's in a controller, filter, or other configuration. If the error log the framework writes in response to that doesn't have the Trace and Span IDs, it's much harder to track down related logs, so this doesn't seem like good default behavior and I would wager most web server frameworks don't behave like this. Anecdotally I can say the ones I've worked with don't.
I'd really like a resolution that allows me to just make a change in one place to uniformly ensure that logs (at a minimum error level logs) will have these IDs so long as they are the result of a request, but barring that, I'd at least like the documentation to describe the problem and workarounds in a way that doesn't require very deep understanding of the Spring internals. The way it's written right now is quite difficult to parse and honestly it doesn't quite seem to describe the solution I'm looking for.
I hope that doesn't come across as an unreasonable request, but I suspect that most users using Spring are doing so to make developing a backend easier. If they have to continually dig into the source code of the framework in order to understand the documentation, I don't think the documentation is doing its job well. I frequently feel like I run across problems like this that are much simpler to solve in other frameworks or just with servers written using the raw language APIs.