Avoid double registration of providers

[radcortez]

When useBuiltinProviders from RESTEasy is true, the availableProviders will be automatically discovered by RESTEasy. If availableProviders are also included, RESTEasy will warn about double regisration.

[gsmet]

@cdsap The failure reported above look a bit concerning ^

[gsmet]

I think this makes things a lot more confusing. I'm not saying the new logic is wrong, just that it's very hard to follow.

We need to make sure the purpose of the sets is understandable and the new code is mixing them all to make it work for what you want to achieve and we completely lost the initial semantic.

I can take a stab at it if you don't feel like it.

[radcortez]

I think this makes things a lot more confusing. I'm not saying the new logic is wrong, just that it's very hard to follow.

We need to make sure the purpose of the sets is understandable and the new code is mixing them all to make it work for what you want to achieve and we completely lost the initial semantic.

I can take a stab at it if you don't feel like it.

I agree. I just wanted to minimize the changes. Let me rework this properly.

[cdsap]

Hi @gsmet,
after analyzing one of the failing tests, we have for the last 28 days:

• 1 Flaky execution
• 2 Failing executions

The flaky execution is caused by a 503 Service Unavailable when building the docker image on:

ERROR: failed to solve: registry.access.redhat.com/ubi8/openjdk-21:1.18: failed to resolve source metadata for 
registry.access.redhat.com/ubi8/openjdk-21:1.18: unexpected status from HEAD request to 
https://registry.access.redhat.com/v2/ubi8/openjdk-21/manifests/1.18: 503 Service Unavailable

Similarly, the failing executions are related to a 502 Bad Gateway when requesting registry.access.redhat.com/ubi8/openjdk-21:1.18:

ERROR: failed to solve: registry.access.redhat.com/ubi8/openjdk-21:1.18: failed to resolve source metadata for registry.access.redhat.com/ubi8/openjdk-21:1.18: unexpected status from HEAD request to 
https://registry.access.redhat.com/v2/ubi8/openjdk-21/manifests/1.18: 502 Bad Gateway

What are your thoughts on this? Is the service degradation a temporary issue, or should I avoid building the Docker images during these integration tests?

[gsmet]

I rebased and fixed a small typo, let's merge when CI is green.

[quarkus-bot]

Status for workflow Quarkus CI

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

Failing Jobs

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✖	MicroProfile TCKs Tests	Verify	Failures	Logs	Raw logs	🔍

You can consult the Develocity build scans.

Failures

⚙️ MicroProfile TCKs Tests #

- Failing: tcks/microprofile-opentelemetry 

📦 tcks/microprofile-opentelemetry

✖ Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.5.0:test (tracing) on project quarkus-tck-microprofile-opentelemetry: There are test failures.

Please refer to /home/runner/work/quarkus/quarkus/tcks/microprofile-opentelemetry/target/surefire-reports-tracing for the individual test results.
Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.