Properly initialize reactive Pool beans

[geoand]

We introduce an injection point to the
synthetic bean creation process thus
giving Arc all the declarative context
it needs in order to ensure proper bean
creation order

Relates to quarkiverse/quarkus-vault#167

[gsmet]

Look good overall, I added a small comment.

[tsegismont]

LGTM, thank you @geoand

Just one question about a code comment

[vsevel]

nice change. is the goal to backport this on 3.4.0, and finalize quarkiverse/quarkus-vault#167?

[geoand]

I am not sure we can backport because this breaks the use of some build items (granted they are unlikely to be used)

[vsevel]

hmm. so what do we do for vault in 3.4 ?
I am confused. we actually pulled your branch quarkiverse/quarkus-vault#167 and used it against CR1, and it worked on your sample app.
is this change appropriate in 3.4 (or not)?
if not, what can we do in vault for 3.4? we can't leave the VertxRecorder, can we?

[geoand]

For 3.4 you should use quarkiverse/quarkus-vault#167 which you said seems to work.

This change here in just to sure that we don't run into issues that lead to the use of the VertxRecorder in the first place.

[vsevel]

well. it works in the use case we tested.
if we go ahead then we are probably going to re-ignite issue quarkiverse/quarkus-vault#78, which lead you to do do quarkiverse/quarkus-vault#109 as @kdubb was reporting
it seems that either way we can't have a solution working at 100%.
if we don't do anything we have quarkiverse/quarkus-vault#165 (and nothing works)
and if we do quarkiverse/quarkus-vault#167 we are going to have quarkiverse/quarkus-vault#78

if correct, I think we need to go ahead with quarkiverse/quarkus-vault#167, release vault 3.2, and report in the migration guide that this version does not work with reactive datasources, which will be fixed in 3.5
any other (better) option?

[quarkus-bot]

✔️ 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.

[geoand]

if we go ahead then we are probably going to re-ignite issue quarkiverse/quarkus-vault#78, which lead you to do do quarkiverse/quarkus-vault#109 as @kdubb was reporting

Anyway to verify this?

[vsevel]

any way to verify this?

@vmargerin can you check if we still have the issue with CR1 and quarkiverse/quarkus-vault#167 using quarkiverse/quarkus-vault#78 (comment)?

[vmargerin]

@vsevel @geoand I confirm that the original issue (quarkiverse/quarkus-vault#78 (comment)) reappears with the PR which solves VertxRecorder issue on 3.4.0.CR1.

Quarkus version	Quarkus Vault version	Result
2.16.x	2.1.0 + PG Reactive	jakarta.enterprise.inject.CreationException: Synthetic bean instance for io.vertx.core.Vertx not initialized yet
3.3.3	3.1.0	OK
3.4.0.CR1	3.1.0	ClassNotFound VertxRecorder
3.4.0.CR1	3.2.0-SNAPSHOT (@geoand version) + PG Reactive	jakarta.enterprise.inject.CreationException: Synthetic bean instance for io.vertx.core.Vertx not initialized yet

[geoand]

Thanks @vsevel and @vmargerin.

In that case, we indeed might want to consider this for 3.4... @cescoffier @gsmet WDYT? This is technically breaking as it changes a build item, but it is highly unlikely these build items are used by any external extension.

[cescoffier]

it should be ok, I'm not sure it's an easy backport.

[geoand]

The backport itself should be easy