Support `DefaultWebFilterChain` allowing the current filter to provide its name explicitly

[joebyneil]

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.

spring-framework/spring-web/src/main/java/org/springframework/web/server/handler/DefaultWebFilterChain.java

Lines 112 to 115 in c4e25a1

	private Mono<Void> invokeFilter(WebFilter current, DefaultWebFilterChain chain, ServerWebExchange exchange) {
	String currentName = current.getClass().getName();
	return current.filter(exchange, chain).checkpoint(currentName + " [DefaultWebFilterChain]");
	}

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!

[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?

[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.

[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.