In order to improve the compatibility with JVM Checkpoint Restore (aka CRaC), ReactorClientHttpConnector
should implement the Lifecycle
interface.
Comment From: agorbachenko
@sdeleuze Does it make module spring-web dependency on spring-context mandatory instead of not optional? My project uses ReactorClientHttpConnector explicitly and before spring 6.2 spring-context wasn't required, but now it is (java.lang.NoClassDefFoundError: org/springframework/context/SmartLifecycle)
Comment From: bclozel
This change makes this class depend on spring-context, but spring-web has been optionally depending on spring-context for years. As of Spring Framework 6.1, you'll need spring-context on the classpath to use this class.
Comment From: sdeleuze
I have updated the upgrade notes accordingly.
Comment From: filiphr
I have a similar problem like @agorbachenko. We were using only the spring-webflux
dependency with manually creating our own ReactorClientHttpConnector
with HttpClient
. With the change here it means that we now need spring-context
to keep using this.
I also had a look into this a bit and I don't quite understand how this works for the intended purposes? Let's say I want to use the WebClient.Builder
to create my own instance of the WebClient
public MyBean myBean(WebClient.Builder webClientBuilder) {
// configure the builder for my purpose
WebClient webClient = webClientBuilder.build();
return new MyBean(webClient);
}
Will CRaC work in this example? From what I could see in the smoke tests WebClientConfiguration in the smoke tests the auto configured ClientHttpConnector
is injected and only this approach will work with CRaC, right?
Does it make more sense to have a FactoryBean
for the ResourceFactory
that would implement the Lifecycle
and maybe have a wrapper for a ClientHttpConnector
that would allow for starting / stopping the ReactorClientHttpConnectorFactory
? Or maybe have 2 types, one that is for externally managed and another that is the one from 6.0?
Comment From: sdeleuze
Will CRaC work in this example?
Yes, and that's a good point, I have refined the smoke test to not customize the ClientHttpConnector
anymore. This is possible thanks to Spring Boot configuring the connector at builder level here.
That's IMO one more reason to keep things as they are implemented, and just add the additional spring-context
dependency which will just be used for SmartLifecycle
and related types.
Comment From: filiphr
Thanks for the pointer @sdeleuze. I missed that class, seems like IntelliJ isn't finding that usage if I use the auto configure as a dependency only.
We went with adding the spring-context
in this scenario, it makes sense to have.