Hello there,
I think it might have been discussed several times (e.g. viewtopic.php?f=26&t=998743): but what's the reason for not exposing the currently validated bean (e.g. through ConstraintValidationContext) when validating a field or property? So, why are values validated "in isolation"? Is this for performance reasons?

Essentially, my use case is kind of cross-field validation. I know, Class level constraint are the way to go here, but as I'll add many constraints for multiple fields, there would end up a huge amount of annotations on the class declaration. It would be much prettier if I was able to do this:



Looking at Hibernate Validator RI, technically, the implementation could easily expose the bean. When validating the property the ValueContext contains the bean but only the value-to-be-validated is passed: see ConstraintTree.class:278:



Well, currently, I could live with a workaround (is there any way to access the bean from within the validator when validation a property value?), but I'd really like to understand why this restriction exists. And yeah, you asked for improvements on BVAL 1.1 - I think this one would not just help me ;)

Thanks for any hints!
Best regards,
Vivian

Hi Vivian,

thanks for your feedback.

I guess so far there was just no real need/request for exposing the validated bean to the validator in case of property validation. As you said class-level constraints are Bean Validation's answer to cross-field validation. In case you have multiple cross-validation requirements for one bean you still might use one constraint and validator dedicated to that bean which performs all required validations.

That said I personally like the idea of making the bean available via ConstraintValidationContext and created BVAL-237 to further investigate this.

I don't think though that we'll see things like @Min("#{this.x}") in the spec. as the same in general leans very much towards type-safety. But exposing the bean would allow BV providers or users to create custom constraints of that kind. In Hibernate Validator for instance there is the ScriptAssert constraint which might be applied to fields/properties based on such an addition.

At the moment I don't see a way for accessing the bean within your validators, you might consider using the @ScriptAssert constraint I mentioned.

Hth,

--Gunnar

Gunnar, thanks very much for your prompt response. I'd be very glad to see BVAL-237 be accepted in an upcoming JSR MR!

Of course, the expression stuff does not have to go into the spec. It's quite sufficient if we implement these things in applications but doing so in a portable way would be great.
I'm currently writing my diploma thesis on a project that heavily relies on constraints. While investigating literature on constraint programming, I recognized that the current BVAL constraints can be seen as unary constraints (they restrict exactly one variable, that is, the value of the field/method that is annotated with the constraint annotation). With the expression stuff I'm trying to build binary and maybe even n-ary constraints, which allow expressing relations between variables. As you already pointed out, this is currently only possible with @ScriptAssert (maybe this one should finally go into the spec as well? ;)).

Maybe you'll here more requests from my side, regarding alignment to constraint programming approaches, if that's okay ;)

Finally, again on the topic of exposing the bean. Do you thing we could expose the ValueContext/rootBean/leafBean in Hibernate Validator to the ConstraintValidationContext already, so that we I could at least implement these constraints as Hibernate specific constraints?

Just FYI, the OVal validation framework also allows accessing the validated bean, see http://oval.sourceforge.net/userguide.html#d4e493 (first parameter of the isSatisfied method).

Again, thanks, Gunnar!

Resurrecting the thread :)

One use case I'd love to have supported is being able to access the validated bean property/field/method from the MessageInterpolator, and being able to change the variable map used in the interpolation algorithm.

It would make possible, for example, to use field names in the error message: "'name' is required", or to use a second annotation (say, @FieldName(String)) to declare its name.

In both the 1.0 spec and hibernate-validator 4.2, this is not possible, since the MessageInterpolator.Context implementation doesn't hold this information, and the ResourceBundleMessageInterpolator.interpolateMessage() method is private, so even if we override the interpolate() methods, we couldn't manipulate the variable map ('annotationParameters') that is passed for interpolation.

And I don't think just adding these variables to the standard variable map is sufficient. It would much better to specify hooks for framework/application-specific extensions.

Ronald, also quite an interesting use case. Without fiddling with the code in detail, but I think your use case could be easily implemented if https://hibernate.onjira.com/browse/BVAL-237 (BVAL 1.1 spec) and/or at least https://hibernate.onjira.com/browse/HV-514 (HV specific) was fixed.
So, if not already done so, please vote for these issues and optimally cross-post your use case as a comment of the JIRA issue.

I'd really like to do some promotion for these issues to be addressed. In fact, framework specific extensions are hardly possible at the moment without some deeper integration possibilities like these.

Thanks a lot!