When AutoConfigurationReproTests
was introduced, it was testing some code in EmbeddedServletContainerAutoConfiguration
that registered a EmbeddedServletContainerCustomizerBeanPostProcessor
bean if one had not already been defined. That post-processor has now become WebServerFactoryCustomizerBeanPostProcessor
that's registered by ReactiveWebServerFactoryAutoConfiguration
or ServletWebServerFactoryAutoConfiguration
.
Comment From: siripuramGanesh
The test AutoConfigurationReproTests was actually testing code in EmbeddedServletContainerAutoConfiguration, where it was verifying whether or not the EmbeddedServletContainerCustomizerBeanPostProcessor was registered if it wasn't already defined. Recent refactorings have though replaced this post-processor with the WebServerFactoryCustomizerBeanPostProcessor, which is now registered by either ReactiveWebServerFactoryAutoConfiguration or ServletWebServerFactoryAutoConfiguration.
This would likely require the test cases to be changed to incorporate the new post-processor. It would be a good idea to alter the tests so they can properly check the right behavior of the new configuration, that it does work with the new WebServerFactoryCustomizerBeanPostProcessor registration mechanism.
Comment From: wilkinsona
That’s a rehash of the existing description. It also reads like it was generated by an LLM. Such spam isn’t welcome in our issue tracker as it adds no value.
Comment From: wilkinsona
In fact, we can delete the class entirely as the post-processor and the potential for it to trigger early initialization is covered by WebServerFactoryCustomizerBeanPostProcessorTests
.