Import ErrorWebFluxAutoConfiguration with @WebFluxTest

[alimate]

It's worth mentioning that the imported auto-configuration will register a bean of type ErrorWebExceptionHandler if there is no such bean already in the application context. So in order to provide a custom handler, we need to register a bean of type ErrorWebExceptionHandler, not the WebExceptionHandler.

Closes #16258
Related Issue #13627

[mbhave]

@alimate Could you explain why this change is necessary?

[alimate]

@mbhave Apparently, As part of the #13627, We support the WebExceptionHandlers in WebFluxTests. As far as I know, this behavior is inconsistent (Please correct me if I'm wrong) with when we run Spring Boot applications manually. In the latter scenario, we should register a bean of type ErrorWebExceptionHandler (Not of type WebExceptionHandler) to disable the default error handling and use a custom approach for error handling.

Basically, here I'm implementing the ErrorWebExceptionHandler interface to align error handling in automatic and manual testing scenarios.

Also, I'm registering this new handler conditionally to test both of the following:

• When there is no ErrorWebExceptionHandler registered, the default one provided by the ErrorWebFluxAutoConfiguration should be used.
• Otherwise, Spring Boot discards the default one and registers our custom ErrorWebExceptionHandler.

[mbhave]

Thanks for the explanation. I think we'd still want to keep the WebExceptionHandler to make sure that those get picked up by @WebFluxTest. For testing that the ErrorWebFluxAutoConfiguration is imported, the test that you've added in WebFluxTestAutoConfigurationIntegrationTests should suffice.

Let's see what @bclozel thinks.

[alimate]

I've created a sample repo for this inconsistent behaviour
https://github.com/alimate/webflux-Inconsistency

[bclozel]

This is not a case of ErrorWebExceptionHandler vs. WebExceptionHandler, since ErrorWebExceptionHandler is extending WebExceptionHandler after all.

This is more about the ordering of the beans - by default Spring Boot configures the ErrorWebExceptionHandler instance at order -1 to make sure to handle errors before the WebExceptionHandler provided by Spring WebFlux.

An application can still configure a WebExceptionHandler earlier to process errors before the handler provided by Spring Boot.

In short, I agree with @mbhave and the @ConditionalOnProperty change is not necessary.

[alimate]

@bclozel Thanks. So instead of registering the ExampleWebExceptionHandler as a Component, we're better off registering it manually using a @Bean with different Orders, right?

[alimate]

Anyway, I removed the Component and ConditionalOnProperty annotations from the ExampleWebExceptionHandler.

Instead, I registered the exception handler using a @Bean with different priorities to test the fact that WebExceptionHandlers with appropriate Orders would be called before the default handler provided by the ErrorWebFluxAutoConfiguration.

What do you think? @bclozel @mbhave

[mbhave]

@alimate I don't think we need to change anything related to ExampleWebExceptionHandler. The fact that a WebExceptionHandler can be configured with a higher precedence than the one provided by Spring Boot doesn't need to be tested in a test for @WebFluxTest. This issue is about ensuring that ErrorWebFluxAutoConfiguration is imported by @WebFluxTest and I think the only tests you need to change for that are WebFluxTestAutoConfigurationIntegrationTests.

[alimate]

@mbhave OK. I'm reverting back some of the changes 👍

[snicoll]

@alimate thank you for making your first contribution to Spring Boot. This is now merged in 2.1.x and master with a polish commit as one test was still failing.