Do not rely on JPATraversableResolver / add JPA aware resolver only if ORM is enabled

[marko-bekhta]

This PR tries to address a few things

• The upgrade to Hibernate Validator 9.0.1 Bump org.hibernate.validator:hibernate-validator from 9.0.0.Final to 9.0.1.Final #48380 (comment)
• "simplification" of the traversable resolver that is part of the Hibernate Validator. I may have "oversimplified" it here but here are my thoughts. Since the change to cache the persistence utils in the built-in JPATraversalbeResolver I was thinking that we could skip even more operations when we are within Quarkus. From what I can see the current implementation in the JPA would eventually delegate to ProviderUtil that have its own implementation in Quarkus, which is shared by ORM/Reactive. I was thinking that we could also try to eliminate the extra calls to retrieve the persistence providers and also the loops if we know that all we'd get is ProviderUtil.
• Since the "predicate" to delegate the resolver check is now added only if ORM is enabled, it should also address the problem with the native build mentioned here: @Valid throws NPE if hibernate-orm is disabled in native mode #48270

[quarkus-bot]

/cc @gsmet (hibernate-orm)

[geoand]

Usually SPI modules aren't optional, because the presence of the SPI doesn't mean that the actual extension that leverages the build items (in this case quarkus-hibernate-validator-deployment)

[marko-bekhta]

Thanks, got it 😃 ! Let me clean it up and see if it all still works (it should, right? but 😃)

[geoand]

It should yeah :)

[github-actions]

🎊 PR Preview 2c5bbae has been successfully built and deployed to https://quarkus-pr-main-48458-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 28a73f6.

✅ 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.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[gsmet]

I'm wondering if we are not pushing things a bit too far but only time will tell :).

Thanks for the PR!