[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ] Scott Marlow edited comment on WFLY-13734 at 8/4/20 11:00 AM: -------------------------------------------------------------- [~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. was (Author: smarlow): [~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. -- This message was sent by Atlassian Jira (v7.13.8#713008)