Fix providers not auto registered for JAX-RS Client

[radcortez]

Fixes #11424

[kenfinnigan]

Happened to see this, and I'm not sure how this fix works.

A change has been made in resteasy-server-common, but that artifact isn't used by rest-client. From the issue it seemed this problem occurred with REST Client when the server isn't present, or am I mistaken?

[radcortez]

Hi @kenfinnigan

Common is used here:

quarkus/extensions/rest-client/runtime/pom.xml

Lines 26 to 29 in 193ebe2

	<dependency>
	<groupId>io.quarkus</groupId>
	<artifactId>quarkus-resteasy-common</artifactId>
	</dependency>

The issue only occurs with the programmatic REST Client ClientBuilder.getClient() and when there is not another class annotated with @Path in the application. This prevents the RESTEasy server to start and annotated Providers are not auto registered with the programmatic client.

[radcortez]

The proposal is to use the same solution that was used in Quartz:
https://quarkus.io/guides/quartz#quarkus-quartz_quarkus.quartz.force-start

To have a config that force starts the server.

The programmatic REST Client does work without the RESTEasy server, is just doesn't auto register scanned metadata like Providers. Another possible solution would be to auto start the server if we detect user Provider classes, but it doesn't mean that the programmatic REST Client is going to be used so it may be a waste.

[kenfinnigan]

@radcortez Yes resteasy-common is used by REST Client, but the change was made in resteasy-server-common, which is a different dependency.

That's why I wasn't sure if the change actually worked when just using REST Client with no JAX-RS endpoints

[radcortez]

Hum, maybe you are right. The dependency is there, but as test in the extension. Let me try it out with a real project.

[radcortez]

Found an easier way to do it.

Plus, I believe we could probably get rid of this:
https://github.com/quarkusio/quarkus/blob/b406f7ac160389fdcf19ef95225afbdea7a48441/extensions/rest-client/runtime/src/main/java/io/quarkus/restclient/runtime/graal/ClientBuilderReplacement.java

[gsmet]

This won't conflict with the server behavior when both are used? /cc @kenfinnigan

[radcortez]

I don't think so. When the server starts (if any) it will replace the instance:

https://github.com/resteasy/Resteasy/blob/1570f6825de1fde1ea3c3a950dcb6297e3c9bd4f/resteasy-core/src/main/java/org/jboss/resteasy/core/ResteasyDeploymentImpl.java#L377

And it will work for both server and client with the right factory.

[kenfinnigan]

Is the ResteasyDeploymentImpl used in Quarkus, for some reason I'm thinking it isn't, but could easily be wrong?

If we do use it, then I think it should work fine. But certainly worth verifying

[radcortez]

Yes, it is used here:
https://github.com/quarkusio/quarkus/blob/5941a39ba4c1eecedd854f74b4d9e688082a73fc/extensions/resteasy-server-common/runtime/src/main/java/io/quarkus/resteasy/server/common/runtime/QuarkusResteasyDeployment.java

[kenfinnigan]

Thanks for checking

[FroMage]

Famous Last Words™

[gsmet]

@kenfinnigan could you approve it if everything is good for you? Thanks!