Change the JsonRPC Service for OIDC to use recorder

[phillip-kruger]

This is for #44181. It does not fix it, but takes Dev UI out of the picture.

This PR change the way we make data available to the JSON RPC service. It now use a recorder to record it directly on the JsonRPC Service.

On another note, we can probably use build time data (that can also accept a runtime value) for some of the json-rpc methods. However this is a bigger and riskier change (with the same result) so I kept it simple. If the maintainers (@sberyozkin) wants to pursue this I can show what I suggest.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 0d98259.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 integration-tests/oidc-code-flow

✖ io.quarkus.it.keycloak.CodeFlowTest.testTokenRefresh - History

• expected: <true> but was: <false> - org.opentest4j.AssertionFailedError

org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
	at io.quarkus.it.keycloak.CodeFlowTest$3.call(CodeFlowTest.java:733)
	at io.quarkus.it.keycloak.CodeFlowTest$3.call(CodeFlowTest.java:720)
	at org.awaitility.core.CallableCondition$ConditionEvaluationWrapper.eval(CallableCondition.java:99)
	at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:248)
	at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:235)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)

[michalvavrik]

lgtm; I am not sure I agree it doesn't fix the issue, isn't remaining issue duplicate of the #39644 ?

[michalvavrik]

On another note, we can probably use build time data (that can also accept a runtime value) for some of the json-rpc methods. However this is a bigger and riskier change (with the same result) so I kept it simple. If the maintainers (@sberyozkin) wants to pursue this I can show what I suggest.

I am interested.

[sberyozkin]

Thanks @phillip-kruger @michalvavrik, I'll quickly try this PR with both Keycloak and non Keycloak provider, soon and merge then

[phillip-kruger]

On another note, we can probably use build time data (that can also accept a runtime value) for some of the json-rpc methods. However this is a bigger and riskier change (with the same result) so I kept it simple. If the maintainers (@sberyozkin) wants to pursue this I can show what I suggest.

I am interested.

@michalvavrik - So for the getProperties method, that can move to a BuildTimeAction. This means that you do not need to create a JsonRPC method, you just provide the code in the deployment module. See https://quarkus.io/guides/dev-ui#jsonrpc-against-the-deployment-classpath

The BuildTimeAction can also take a RuntimeValue that will be returned, meaning you can record the data in the recoreder, and that will be returned on the getProperties call.

[sberyozkin]

Tested with Keycloak and Auth0, thanks @phillip-kruger

[michalvavrik]

On another note, we can probably use build time data (that can also accept a runtime value) for some of the json-rpc methods. However this is a bigger and riskier change (with the same result) so I kept it simple. If the maintainers (@sberyozkin) wants to pursue this I can show what I suggest.

I am interested.

@michalvavrik - So for the getProperties method, that can move to a BuildTimeAction. This means that you do not need to create a JsonRPC method, you just provide the code in the deployment module. See https://quarkus.io/guides/dev-ui#jsonrpc-against-the-deployment-classpath

The BuildTimeAction can also take a RuntimeValue that will be returned, meaning you can record the data in the recoreder, and that will be returned on the getProperties call.

I put it on my list and will apply it before long, thanks @phillip-kruger

[phillip-kruger]

With this new change (#44700) it's less important, as we will remove all dev ui runtime from prod builds, so moving things to BuildTimeActions not really needed.

[michalvavrik]

With this new change (#44700) it's less important, as we will remove all dev ui runtime from prod builds, so moving things to BuildTimeActions not really needed.

good, thanks really

[michalvavrik]

I'll add a backport label so that #45360 can be fixed.

[geoand]

👍🏽