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.