Hey 👋
I'm currently working with a spring based project that wraps certain WebFilters in an instrumentation decorator. Because of this, the checkpoint in DefaultWebFilterChain outputs the class name of the wrapper rather than the underlying filter.
https://github.com/spring-projects/spring-framework/blob/c4e25a1162f88e7b53dcfc8a3658608bf400ea3e/spring-web/src/main/java/org/springframework/web/server/handler/DefaultWebFilterChain.java#L112-L115
eg. DefaultWebFilterChain -> InstrumentationDecorator -> ConcreteWebFilter will checkpoint the name as "InstrumentationDecorator [DefaultWebFilterChain]". Our ideal is "ConcreteWebFilter [DefaultWebFilterChain]", or even just "ConcreteWebFilter".
I'm hoping that we could either: - Disable the checkpoint in DefaultWebFilterChain OR - Provide the name of each WebFilter explicitly
Thanks for your help!
Comment From: rstoyanchev
It's not easy to provide such a fine-grained config option, and this is a couple of levels removed from WebHttpHandlerBuilder which builds the chain, so no easy way to override protected methods either. The wrapping also makes it a challenge for us to introspect a filter and get a name from it, unless there is a way to unwrap or even with some additional interface, the wrapper would have to also implement it.
We could use the toString method in addition to the classname. Would that help, i.e. does the wrapper have a helpful toString implementation?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: joebyneil
It's not easy to provide such a fine-grained config option, and this is a couple of levels removed from WebHttpHandlerBuilder which builds the chain, so no easy way to override protected methods either. The wrapping also makes it a challenge for us to introspect a filter and get a name from it, unless there is a way to unwrap or even with some additional interface, the wrapper would have to also implement it.
We could use the toString method in addition to the classname. Would that help, i.e. does the wrapper have a helpful toString implementation?
In our use case, the wrapping class can definitely implement an additional interface or method from the interface if we needed to.
Could one option be to have a default filterName() {} in the interface that just matches the current implementation by returning the class name?
ToString() would probably work for us too, but I'm suspicious that it might be generally worse for the basic user who isn't wrapping their classes. Potentially using the default toString would add additional text in logs that isn't very useful, and maybe comes with unexpected cost increase for some.
Comment From: rstoyanchev
Yes, we could add a name property with a default implementation that returns the class name.
Comment From: rstoyanchev
On further thought, toString() is more flexible. The wrapping filter can show information about itself and the target vs just a name, which is more limiting.