In the feedback forum a user suggested to expose the currently validated bean via javax.validation.ConstraintValidatorContext.
IMO that's a good addition as it would people allow to create custom cross-field constraints more easily. I'm not sure whether access should be restricted to the current leaf bean or whether also the root bean should be accessible. In the latter case some methods from ConstraintViolation might just be offered on ConstraintValidatorContext as well:
Another idea would be to have an unwrap() method on ConstraintValidatorContext which would allow for BV providers to expose additional functionality. WDYT?
Emmanuel, I don't really agree with your argumentation about the reliance on the presence of the bean object. What's the problem with that? Obviously, the best use case is cross-field-validation: validateValue would anyway not give proper results, as a possible cross-field constraint isn't validated at all? So, it would maybe be a better idea to perform validation on the entire bean scoping only a single property?
Wouldn't it be possible to include the patch in https://hibernate.onjira.com/browse/HV-514 into HV apart from the discussion, whether this is a good practice or not?
Removing from 1.1 as I am still not convinced this won't open the pandora box but each impl can use the unwrap method do offer these.
We have a custom web platform, that automatically validates method calls, via BV's method validation API. Different methods belong to different applications, thus their messages should come from different resource bundles. We would like to be able to use a different resource bundle based on the method being validated - having access to the method/bean being validated in the message interpolator or the ResourceBundleLocator SPI would help us solve this.
So +1 from us.
@arik, this issue is about ConstraintValidatorContext, but you seem to ask for the validated bean in the MessageInterpolationContext. Even though that is also not part of the spec, you can use the the unwrap method for the case where you use Hibernate Validator as Bean Validation provider. Something like this:
That’s really unfortunate that for 7 years such a simple fix hasn’t been added to hibernate validator, and that’s because “in some situations this bean would be null”. So what?
Note that without this feature you cannot do any contextual validation with hibernate validator, like for example this:
If you want to use this entity to represent users from different countries, and you want to implement @GovId validator so that it uses different validation for users from different countries, you currently cannot do it with hibernate validator because there’s no way to access country field of the User entity from the validation context.
Fortunately there’s a way to do it using beans validation implementation from Micronaut framework which apparently doesn’t have a problem with injecting root bean into the validation context.