WsConfigurer can trigger early initialization that prevents other post processors to run successfully

[N4zroth]

Hi,
as said in the title if I have a Configuration that extends WsConfigurerAdapter with a direct or transitive dependency to ObservationRegistry, ObservationRegistryPostProcessor.postProcessAfterInitialization is never called with ObservationRegistry as argument, thus bricking tracing for the whole project. I'm not sure what's the cause, my best guess is that some initialization order gets messed up.
You can see a small sample project here https://github.com/N4zroth/ws-tracing , both tests should work but only one is green. This seems similar to spring-projects/spring-security#15658 but isn't fixed even with Spring Boot 3.3.4 and spring-ws 6.1.13.

[N4zroth]

@corneil just updated the project with newest spring boot dependency and it still fails.

[corneil]

@N4zroth Thanks for the reproducer. I am looking into the root cause.

[corneil]

@N4zroth Can you provide more information as to what you would like to do with the ObservationRegistry within the WsConfigurerAdapter?

[N4zroth]

@corneil sure - we have an indirect dependency, we need a feign client that we initialize ourselves with feign-micrometer (for authorization purposes). The example with a simple dependency was just simpler to do :)

…

On Wed, Nov 6, 2024, 14:02 Corneil du Plessis ***@***.***> wrote: @N4zroth <https://github.com/N4zroth> Can you provide more information as to what you would like to do with the ObservationRegistry within the WsConfigurerAdapter? — Reply to this email directly, view it on GitHub <#1435 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7HHOPSNS52SEOWXVLGYMTZ7IHQBAVCNFSM6AAAAABP7Y3XZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJZGY4TQMBWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[corneil]

If you move the bean configuration of feign client to a different configuration class you should not encounter this problem.

[N4zroth]

The configuration of the Feign Bean is already a different Configuration class. This class only has a dependency on the generated Feign Bean.

[N4zroth]

I updated the example with an example including Feign

[corneil]

By injecting the FeignClient into the WsConfig you have the same condition. Forcing the ObservationRegistry to be created before the Web Server is causing the problem.

You can make a change so that WsConfig implements ApplicationListener<ContextRefreshedEvent> and add a method like:

@Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        configureFeignClient(event.getApplicationContext().getBean(FeignClientExample.class));
    }

Assuming that configureFeignClient will do what is required using the provided parameter.

[N4zroth]

But why is this the case? Shouldn't it be possible to do it 'the normal way'? It looks similar to spring-projects/spring-security#15658 which was fixed some time ago.

[corneil]

If ObservationRegistry is created before the web container we have a problem.
Even if you use an ObjectProvider to delay creation, when you use the object in WsConfig before the Web container is initialized then it doesn't properly initialize the ObservationRegistry.

The best is to hook it in after the context is refreshed. Then you can also deal with dynamic changes in configuration like when using Spring Cloud Config.

[hpoettker]

Isn't this bug a consequence of #1425 and #1391?

The WsConfigurerAdapter and its sub-classes are not eligible to be postprocessed by all bean post-processors like the ObservationRegistryPostProcessor.

Resolving #1425 should also fix this issue, if I understand correctly.