Dev services (new model?) may not apply "additional configuration provider"'s config properly

[yrodiere]

Describe the bug

See https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2349.20Dev.20Service.20Lifecycle.20chat/near/574964695, @holly-cummins asked for a tracker

While working on #52692 I stumbled upon some peculiar behavior... I end up in a case where Hibernate ORM's "additional configuration provider" gets called, and consequently requests the value of schema-management.strategy being forced to drop-and-create, but... this is only taken into account for the default persistence unit, not for a named one.

This result in Hibernate ORM's schema management not being enabled automatically for named persistence units, which is definitely a bug.

While debugging I noticed the additional config provider (strangely) gets called twice per persistence unit with different parameters, but that doesn't seem to be the root of the problem (see below).

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

1. Check out https://github.com/yrodiere/quarkus/tree/hibernate-orm-dev-service-schema-management-drop-and-create-ignored
2. Alternatively, check out Remove pointless settings from Hibernate-related integration tests + use dev services in a few more integration tests #52692 and revert the commit with message Work around https://github.com/quarkusio/quarkus/issues/52699
3. Build with -Dquickly
4. Run ./mvnw clean verify -Dstart-containers -Dtest-containers -f integration-tests/hibernate-reactive-panache -Dtest=NamedPersistenceUnitsTest
5. Notice how the schema was not created automatically for persistence unit secondary
6. Do not despair

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

To investigate further:

1. Put breakpoints:
   1. Here to see the effective value of schema-management.strategy: https://github.com/yrodiere/quarkus/blob/02b54c7fdb7b55ad4c2ed178493693088de6afd1/extensions/hibernate-reactive/runtime/src/main/java/io/quarkus/hibernate/reactive/runtime/FastBootHibernateReactivePersistenceProvider.java#L406
   2. Here to see the additional configuration provider in action: https://github.com/yrodiere/quarkus/blob/3e0bad96094be2225e3b3696ad0170f25aea368d/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/dev/HibernateOrmDevServicesProcessor.java#L57
2. Run ./mvnw clean verify -Dstart-containers -Dtest-containers -f integration-tests/hibernate-reactive-panache -Dtest=NamedPersistenceUnitsTest -Dmaven.surefire.debug
3. Connect your debugger (port 5005)

Strangely:

1. The breakpoint gets hit twice for each persistence unit: the first time with username/password config, yielding correct "additional config", and the second time with reactive URL config, yielding incorrect "additional config".
2. That in itself doesn't seem to be the problem, because the <default> persistence unit / datasource seems to behave correctly (schema-management.strategy is set correctly to drop-and-create and acted upon), and only the secondary persistence unit / datasource does not (schema-management.strategy is set to its default, none). Also, changing the additional configuration provider, so that it yields correct "additional config" even when provided only with a URL, does NOT work around the problem.

[quarkus-bot]

/cc @geoand (devservices), @holly-cummins (devservices), @ozangunalp (devservices)

[quarkus-bot]

You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip

_{This message is automatically generated by a bot.}

[cescoffier]

🤖 Automatically associated with the WG - Dev Services Lifecycle Working Group based on AI classification.

[holly-cummins]

I did notice that we now set up the additional config twice, once at build-time, and once in the post-build-pre-runtime-liminal-phase-without-a-name. It seemed harmless, if not ideal, but that might be related to this. (It also wasn't easy to think of a better pattern, which is why I didn't just fix it.)