OpenAPI: Added support for quarkus.resteasy-reactive.path

[phillip-kruger]

Fix #19434

@geoand - I think a better fix would be that RestEasy Reactive also produce a ResteasyJaxrsConfigBuildItem like the RestEasy classic ?

Signed-off-by:Phillip Kruger [email protected]

[quarkus-bot]

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building f319f7f

Status	Name	Step	Test failures	Logs	Raw logs
✔️	JVM Tests - JDK 11
✖	JVM Tests - JDK 11 Windows	Build	⚠️ Check →	Logs	Raw logs
✔️	JVM Tests - JDK 16

[quarkus-bot]

Failing Jobs - Building f319f7f

Status	Name	Step	Test failures	Logs	Raw logs
✖	Native Tests - Messaging2	Download Maven Repo	⚠️ Check →	Logs	Raw logs

[ebullient]

@geoand - I think a better fix would be that RestEasy Reactive also produce a ResteasyJaxrsConfigBuildItem like the RestEasy classic ?

The problem is that the two extensions have zero common classes (including build items). Part of why I moved all of the resteasy stuff into the "resteasy-classic" directory was to really emphasize that even though some of those have "common" in the name.. they aren't common between reactive and classic, only between resteasy server and client.

[ebullient]

Amendment: What would have been better, IMO, was for both extensions to use quarkus.rest.path, since they can't be used at the same time anyway. Making all downstream extensions understand two config attributes is.. meh. But that's just my opinion. ;)

[phillip-kruger]

+1 on that

[stuartwdouglas]

I am also +1 on using quarkus.rest.path

[phillip-kruger]

@stuartwdouglas @ebullient - At the moment we have quarkus.resteasy.path and quarkus.resteasy-reactive.path and we want both of those to also support quarkus.rest.path ? Is that something we want as part of this PR ? Or should I just add support for
quarkus.rest.path here and once it's in RestEasy this will work (still supporting the old properties as well) ?

[stuartwdouglas]

I would just deprecate quarkus.resteasy-reactive.path and update RR to support quarkus.rest.path. I don't know if I would even bother making quarkus.resteasy-reactive.path work.

[phillip-kruger]

@stuartwdouglas ok cool. I am a bit concerned that the reversed has happened it seems (see this comment: #19434 (comment)) from @ebullient . So I am worried that there was a reason that rest.path was deprecated in favor of the other two and now we are revering it ? Also, is there as shared common module used by both classic and reactive that can host this property ?

[stuartwdouglas]

Oh ok, reading the issue I assumed that quarkus.rest.path was used by Resteasy Classic, but it appears this is not the case. I think this PR is ok as is then.

[phillip-kruger]

Thanks @stuartwdouglas :)

[gsmet]

Yes, I prefer we keep it that way rather than introducing a quarkus.rest prefix out of the blue.

I think this should be backported though if we want to make RESTEasy Reactive a first class citizen in 2.2. Adding the label.