Expose validated bean via ConstraintValidatorContext

Description

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?

Environment

None

Activity

Show:
Vivian Steller
June 14, 2012, 10:07 AM
Edited

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?

Emmanuel Bernard
February 12, 2013, 12:52 PM

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.

Arik Kfir
July 23, 2013, 9:06 AM

Hi,

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.

Hardy Ferentschik
July 23, 2013, 9:14 AM

@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:

l0coful
May 14, 2020, 11:37 AM

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.

Assignee

Unassigned

Reporter

Gunnar Morling

Labels

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Affects versions

Priority

Major
Configure