Presence of WsConfigurerAdapter with a dependency to ObservationRegistry prevents ObservationRegistry's post processing and bricks tracing
N4zroth opened this issue · 11 comments
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.
@corneil just updated the project with newest spring boot dependency and it still fails.
@N4zroth Can you provide more information as to what you would like to do with the ObservationRegistry within the WsConfigurerAdapter?
If you move the bean configuration of feign client to a different configuration class you should not encounter this problem.
The configuration of the Feign Bean is already a different Configuration class. This class only has a dependency on the generated Feign Bean.
I updated the example with an example including Feign
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.
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.
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.