Support apache http client engine using httpclient5

[tatsiana-skurydzina-rovio]

Hey.

I have been working with a project that relies on httpclient 5 specific logic and at the same time using pooling http client for http engine

new ResteasyClientBuilderImpl()
                .httpEngine(engine)
                .build();

After update to resteasy 6.2.12.Final, I figured out that there is a lot of deprecated classes without any alternatives, e.g. URLConnectionEngine doesn't allow to configure connection pooling anyhow.

I tried to use even 7.0.0+ Alpha/beta versions but they also contain only deprecated classes. I can see only one alternative for now for myself to provide own ApacheHttpClient5Engine implementation similar to ApacheHttpClient43Engine

Could someone suggest better ideas how is it supposed to be done?

[jamezp]

Hello @tatsiana-skurydzina-rovio,
The Apache HTTP Client 4.x was deprecated because we need to end up providing a newer version of the client. In my opinion, we've exposed too much of this as well and the client implementation should be more hidden.

By "httpclient5", do you mean the Apache HTTP Client 5.x? If so, RESTEasy itself does not have an implementation for that.

With 6.2.12.Final and 7.0.0.Beta1, we better expose an API for creating custom engines. What I think we should be doing is creating these client engines as separate projects so we can independently update them. Then you simply need to include the one you want on the class path.

[jamezp]

Yes, that is my plan. I've not completely implemented it yet of course. But the idea is we could have, as you say, the resteasy-apache-client. Version 1.0.0 is for the Apache HTTP Client 4.x and 2.0.0 would be for the Apache HTTP Client 5, etc.

Another example, is I'd like to have the JDK HTTP Client version too which is maybe the default if another is not defined. However, there limitations to it.

[ed-erwin-tf]

With 6.2.12.Final and 7.0.0.Beta1, we better expose an API for creating custom engines.

Can you state what that API is? I cannot find anything in the release notes for 6.2.12.Final.
Also, maybe update the deprecation note in ApacheHttpClientEngine to mention the new API.

[jamezp]

The issue was https://issues.redhat.com/browse/RESTEASY-3539. There is a note on https://docs.resteasy.dev/6.2/userguide/#_transport_layer, however I see it doesn't really standout so much:

If you include a META-INF/services/org.jboss.resteasy.client.jaxrs.engine.ClientHttpEngineFactory and an implementation of the interface, you do not need to register your engine in the ClientBuilder. You can simply do Client client = ClientBuilder.newClient() and your backing engine will be used.

I'll have to think about how we document that better. For all the implementations provided via the RESTEasy project, those just need to be on the class path.

[ed-erwin-tf]

Thanks, this link helped:

There is a note on https://docs.resteasy.dev/6.2/userguide/#_transport_layer

The source code for ApacheHttpClientEngine simply says that it is deprecated, but doesn't point to any documentation. That link above could be added to make it more clear.

I am trying to update some old code written by someone else. As far as I can tell, they were specifying this particular engine solely because we need to make sure that it uses the SystemDefaultRoutePlanner so that it uses system defaults to determine a proxy. How might I set that route planner without specifying a specific HttpClientEngine?

SystemDefaultRoutePlanner routePlanner = new SystemDefaultRoutePlanner(null);
CloseableHttpClient httpClient = HttpClientBuilder.create()
  .setRoutePlanner(routePlanner)
  .build();
ApacheHttpClientEngine httpClientEngine = ApacheHttpClientEngine.create(httpClient);
clientBuilder.httpEngine(httpClientEngine);

[jamezp]

Ah, okay that makes sense.

The main reason for the deprecation was less about this other way of exposing the engine to the client, and more about we shouldn't have publicly exposed the Apache HTTP Client 4 implementation the way we did. I only deprecated it because I want the implementation to be more "hidden" so to speak. Plus we really need to start support HTTP/2 and potentially HTTP/3 and having an effective public API for the client engine implementation makes that harder.

That said, feel free to ping me to ask questions about this. It can always help me understand or make the API better :)