Fix unregistered element accesses when using Hibernate ORM in native mode

[zakkak]

Registers:

• Hibernate service providers for native run-time access
• jakarta.validation.ConstraintViolation unconditionally
• com.github.benmanes.caffeine.cache.NodeFactory#FACTORY for reflection

Relates to #41995

[quarkus-bot]

/cc @gsmet (hibernate-orm)

[gsmet]

Looks fine to me but let's make sure @yrodiere has a look at it before merging.

[yrodiere]

Thanks.

Some of the changes definitely make sense, but others are suspicious... it seems you end up having to register services that should only be retrieved during static init. I wonder if it's a case of misdetection? Or maybe these services are retrieved at runtime, even though they shouldn't be?

[yrodiere]

Alternatively, we could skip this code when the HIBERNATE_VALIDATOR capability is not present:

quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/boot/FastBootMetadataBuilder.java

Line 479 in b4b93ad

integrators.add(new BeanValidationIntegrator());

And then we'd be able to keep the if in this method, because BeanValidationIntegrator.isBeanValidationApiAvailable wouldn't be called when the if condition is false.

Though maybe that "optimization" is not worth it, I don't know.

[zakkak]

Seems reasonable, but I don't know how to check if the validator capability is present.

[zakkak]

Thanks for the review @yrodiere. Comments addressed.

[yrodiere]

I force-pushed a fix to the unordered imports in the first commit. Rebased on main while I was at it.

I'll try to add a commit to address the Hibernate Validator capability check.

[zakkak]

I force-pushed a fix to the unordered imports in the first commit. Rebased on main while I was at it.

I'll try to add a commit to address the Hibernate Validator capability check.

@yrodiere It looks like we need the following patch as well:

diff --git a/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java b/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java
index f40a528c1d4..a6d0dce484f 100644
--- a/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java
+++ b/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java
@@ -240,10 +240,13 @@ AdditionalIndexedClassesBuildItem addPersistenceUnitAnnotationToIndex() {
 
     @BuildStep
     public void enrollBeanValidationTypeSafeActivatorForReflection(Capabilities capabilities,
-            BuildProducer<ReflectiveClassBuildItem> reflectiveClasses) {
+            BuildProducer<ReflectiveClassBuildItem> reflectiveClasses, BuildProducer<ServiceProviderBuildItem> services) {
         // Accessed in org.hibernate.boot.beanvalidation.BeanValidationIntegrator.loadTypeSafeActivatorClass
         reflectiveClasses.produce(ReflectiveClassBuildItem.builder("org.hibernate.boot.beanvalidation.TypeSafeActivator")
                 .methods().fields().build());
+        // Accessed in jakarta.validation.Validation$GetValidationProviderListAction.loadProviders through
+        // org.hibernate.boot.beanvalidation.BeanValidationIntegrator.integrate
+        services.produce(ServiceProviderBuildItem.allProvidersFromClassPath("jakarta.validation.spi.ValidationProvider"));
         // Accessed in org.hibernate.boot.beanvalidation.BeanValidationIntegrator.isBeanValidationApiAvailable
         reflectiveClasses.produce(ReflectiveClassBuildItem.builder(BeanValidationIntegrator.JAKARTA_BV_CHECK_CLASS)
                 .constructors(false).build());

[yrodiere]

I force-pushed a fix to the unordered imports in the first commit. Rebased on main while I was at it.
I'll try to add a commit to address the Hibernate Validator capability check.

@yrodiere It looks like we need the following patch as well:

diff --git a/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java b/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java
index f40a528c1d4..a6d0dce484f 100644
--- a/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java
+++ b/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java
@@ -240,10 +240,13 @@ AdditionalIndexedClassesBuildItem addPersistenceUnitAnnotationToIndex() {
 
     @BuildStep
     public void enrollBeanValidationTypeSafeActivatorForReflection(Capabilities capabilities,
-            BuildProducer<ReflectiveClassBuildItem> reflectiveClasses) {
+            BuildProducer<ReflectiveClassBuildItem> reflectiveClasses, BuildProducer<ServiceProviderBuildItem> services) {
         // Accessed in org.hibernate.boot.beanvalidation.BeanValidationIntegrator.loadTypeSafeActivatorClass
         reflectiveClasses.produce(ReflectiveClassBuildItem.builder("org.hibernate.boot.beanvalidation.TypeSafeActivator")
                 .methods().fields().build());
+        // Accessed in jakarta.validation.Validation$GetValidationProviderListAction.loadProviders through
+        // org.hibernate.boot.beanvalidation.BeanValidationIntegrator.integrate
+        services.produce(ServiceProviderBuildItem.allProvidersFromClassPath("jakarta.validation.spi.ValidationProvider"));
         // Accessed in org.hibernate.boot.beanvalidation.BeanValidationIntegrator.isBeanValidationApiAvailable
         reflectiveClasses.produce(ReflectiveClassBuildItem.builder(BeanValidationIntegrator.JAKARTA_BV_CHECK_CLASS)
                 .constructors(false).build());

This looks like something that the Hibernate Validator extension itself should add, or bypass... do you have a precise stack trace?

[yrodiere]

Actually we set the validator factory explicitly here in Hibernate ORM:

quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/boot/FastBootEntityManagerFactoryBuilder.java

Lines 187 to 189 in 47ecd0a

	if (this.validatorFactory != null) {
	options.applyValidatorFactory(validatorFactory);
	}

So I wouldn't expect us to rely on the Bean Validation bootstrap.

I suspect the problem you noticed is a result of adding the BeanValidationIntegrator even if the Hibernate Validator capability is not present: in that case we don't set the validator factory explicitly, so the integrator will fall back to trying to bootstrap Bean Validation the "standard way" -- and it should not.

Hopefully the commit I just pushed (which only adds the BeanValidationIntegrator when it makes sense) will solve this, without additional registrations needed.

[yrodiere]

Alright, I've been too optimistic with my push. Will debug locally...

[yrodiere]

Alright, I've been too optimistic with my push. Will debug locally...

Done and pushed a fix. It was just a misnamed contructor parameter confusing the bytecode recording stuff...

[zakkak]

Thank you @yrodiere

Hopefully the commit I just pushed (which only adds the BeanValidationIntegrator when it makes sense) will solve this, without additional registrations needed.

I confirm it does.

[quarkus-bot]

Status for workflow Quarkus CI

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

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