[jboss-jira] [JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present

[Scott Marlow (Jira)]

    [ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353074#comment-14353074 ] 

Scott Marlow commented on WFLY-13734:
-------------------------------------

[~brian.stansberry]
{quote}
Ah, so if there is no ValidatorFactory but ValidationMode.CALLBACK is used, then Hibernate ORM or other JPA impl will reject that at their level?
{quote}

Yes, that is correct, although to pass the Jakarta EE TCK tests, we do need the ValidatorFactory as that is required for Jakarta EE compatible server implementations.  As I see it, we are introducing a non-EE-compatible server mode which I think is okay.

[From JPA 2.2 SPEC|https://jakarta.ee/specifications/persistence/3.0/persistence_3.0-RC2.html#a2394]:
{code}
In Jakarta EE environments, a ValidatorFactory instance is made available by the Jakarta EE container. The container is responsible for passing this validator factory to the persistence provider via the map that is passed as an argument to the createContainerEntityManagerFactory call. The map key used by the container must be the standard property name jakarta.persistence.validation.factory.

In Java SE environments, the application can pass the ValidatorFactory instance via the map that is passed as an argument to the Persistence.createEntityManagerFactory call. The map key used must be the standard property name jakarta.persistence.validation.factory. If no ValidatorFactory instance is provided by the application, and if a Bean Validation provider is present in the classpath, the persistence provider must instantiate the ValidatorFactory using the default bootstrapping approach defined by the Bean Validation specification [5], namely Validation.buildDefaultValidatorFactory().
{code}

{quote}
If so, then maybe instead of exception it would just be an INFO msg in the server log? So if they indeed didn't package their own BV impl, then when it fails the log gives them a hint.
{quote}
I don't think we need to handle CALLBACK mode at all, as Hibernate will fail the deployment for us.  Sorry that I wasn't clear before but I had to be reminded of the above linked spec requirement.  I knew that there was a requirement but I couldn't find the written contract until now.


> JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-13734
>                 URL: https://issues.redhat.com/browse/WFLY-13734
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Brian Stansberry
>            Assignee: Scott Marlow
>            Priority: Major
>
> This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726.  That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation.  It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)