[bv-dev] Cross parameter validation convergence

Emmanuel Bernard emmanuel at hibernate.org
Fri Sep 7 05:29:20 EDT 2012


This is an old comment from Matt that I did not fully understand until now. Here is my reply.

On 29 août 2012, at 17:38, Matt Benson wrote:

>> 
>> So the remaining question is do we also support the type-safe approach in parallel?
>> I am inclined to think yes. We can do it on the same `CrossParameterConstraintValidator`
>> implementation:
>> 
>> 
>>    class CheckRetypedPasswordValidator implements
>>            CrossParameterConstraintValidator<CheckRetypedPasswordParameter> {
>>        void initialize(...) { ... }
>> 
>>        boolean isValid(Object[] parameterValues, ConstraintValidatorContext context);
>> 
>>        boolean isValid(String username, String email, String password, String retypedPassword,
>>                        ConstraintValidatorContext context) {
>>            ...
>>        }
>>    }
>> 
>> If the method validated has a matching signature, we use it, otherwise we use the generic
>> method.
>> 
> 
> I am inclined to think this can be done as an implementation detail of
> a given CPCV.  However, is it intended that multiple CPCV impls might
> be enabled for a given CPC type, each presumably handling a different
> method signature?  It might actually be simpler in the long run to
> promote the type-safe approach such that at most one CPCV with no
> typesafe declarations could be enabled.  Perhaps the spec should
> provide an abstract TypesafeCrossParameterConstraintValidator that
> makes the correct typesafe call.
> Perhaps this class could provide a
> method to check whether a given signature is supported, or this method
> could be specified on the CPCV interface.

It looks like a type-safe approach would indeed be implemented that way
by a bean validation provider. ie implementing a TypesafeCrossParameterConstraintValidator
that would select the expected methods or raise an exception.

But I don't think it would be beneficial for the user to actually expose this class
that could be used in the @Constraint annotation. The main problem is that we need the
user to tell us which type-safe methods need to be considered and that cannot be expressed
fit well in annotations.

The alternative is to ask people to extend this class. I am always concern when we add a class
as opposed to an interface in the spec, so I'm undecided on this approach.

The third alternative is to let people write how methods are selected but provide a helper method
as you said.


More information about the beanvalidation-dev mailing list