Make ReactorClientHttpConnector lifecycle-aware

[sdeleuze]

In order to improve the compatibility with JVM Checkpoint Restore (aka CRaC), ReactorClientHttpConnector should implement the Lifecycle interface.

[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)

[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.

[sdeleuze]

I have updated the upgrade notes accordingly.

[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?

[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.

[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.