Hi, JPA defines for validation mode "auto" that bean validation must occur if a BV provider is present and that no validation shall occur otherwise. What should happen though if a BV provider such as HV is present but it fails to bootstrap? In case of HV this happens if no expression language implementation can be found. Currently, the user has a very hard time to find out about this, as this exception essentially is suppressed (for mode "callback" the exception is raised). Should we raise a specific exception in HV if it cannot be bootstrapped? In ORM, we could handle that one specifically and raise it also if for validation mode "auto" (would have to happen reflectively, though, as to avoid a hard dependency). I can do this change but first wanted to make sure that this is inline with what you all think should be done. Thanks, --Gunnar _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 1 Feb 2017, at 11:33, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: Hi, JPA defines for validation mode "auto" that bean validation must occur if a BV provider is present and that no validation shall occur otherwise. What should happen though if a BV provider such as HV is present but it fails to bootstrap? In case of HV this happens if no expression language implementation can be found. Currently, the user has a very hard time to find out about this, as this exception essentially is suppressed (for mode "callback" the exception is raised). Should we raise a specific exception in HV if it cannot be bootstrapped? In ORM, we could handle that one specifically and raise it also if for validation mode "auto" (would have to happen reflectively, though, as to avoid a hard dependency). I can do this change but first wanted to make sure that this is inline with what you all think should be done. Thanks, --Gunnar _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 7 Feb 2017, at 11:53, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: So the issue is a more general one than I thought. We'll run into the same situation, too, when there is an error in BV's validation.xml or any constraint mapping file (e.g. a reference to a non-existent MessageInterpolator). That error will currently be suppressed with validation-mode auto. I'm wondering whether in BV 2.0 we should define a new sub-type of ValidationException: NoProviderFoundException which is raised by javax.validation.Validation in case no BV provider is found. Then JPA/ORM could specifically ignore this exception in validation-mode auto but let all other exceptions bubble up, letting the user know early on about any issues they have with their validation provider or its config. Thoughts? 2017-02-06 15:53 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > +1 to fail fast with the explicit error in that case. > >> On 1 Feb 2017, at 11:33, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> >> Hi, >> >> JPA defines for validation mode "auto" that bean validation must occur >> if a BV provider is present and that no validation shall occur >> otherwise. >> >> What should happen though if a BV provider such as HV is present but >> it fails to bootstrap? In case of HV this happens if no expression >> language implementation can be found. >> >> Currently, the user has a very hard time to find out about this, as >> this exception essentially is suppressed (for mode "callback" the >> exception is raised). >> >> Should we raise a specific exception in HV if it cannot be >> bootstrapped? In ORM, we could handle that one specifically and raise >> it also if for validation mode "auto" (would have to happen >> reflectively, though, as to avoid a hard dependency). >> >> I can do this change but first wanted to make sure that this is inline >> with what you all think should be done. >> >> Thanks, >> >> --Gunnar >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >