[bv-dev] Constructor validation

[Gunnar Morling]

2011/12/5 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 4 déc. 2011, at 16:50, Gunnar Morling wrote:
>
>>>
>>> - inheritance: you pass a java.lang.Method object of class A to
>>> validateMethodParameters() and an object of class B extending class A
>>> which overrides this method. Which constraints are checked, the ones of
>>> the method declared on class A, the ones declared on the method of class
>>> B or the sum of the methods in A & B?
>>
>> That's a very good question.
>>
>> In fact in Hibernate Validator we don't support parameter constraints
>> in overriding methods at all (so if A#foo() has parameter constraints,
>> B#foo() must not declare any parameter constraints), as this
>> represents a strengthening of preconditions in sub-types for clients
>> of A, which violates the Liskov substitution principle. Some more
>> reasoning can be found in the HV reference guide in section 8.3.1.1
>> [1].
>>
>> I'm preferring this approach, though it is rather conservate. Some
>> "programming by contract" solutions deal with this by OR-ing the
>> preconditions in a method's hierarchy (so an invocation would be
>> valid, if the constraints at A#foo() OR B#foo() are satisfied),
>> actually applying the "weakest" contract in the hierarchy. How is this
>> done in OVal? And does anyone know how it is in Apache BVAL?
>
> Note that return type constraints could be refined theoretically and be compliant with the Liskov substitution principle. We might want to still disallow this to limit confusion. It will all depend on the set of use case we can think of.

In HV we are currently allowing to define additional return value
constraints on methods overridden in sub types, and so far I haven't
heard of any problems with that. AFAICS that's also what most
programming by contract solutions do.

What's your opinion on parameter constraints? Would you prefer to
OR-join them or to prohibit constraints in overridden methods at all?

>>> - When you add a method return value constraint to a parameterized
>>> method and you do Validator.validate(object), thoses constraints are not
>>> evaluated. But when you add a constraint to a getter-style method (which
>>> also looks and actually is a method return value constraint). They are
>>> evaluated by Validator.validate(object). What if someone wants to add a
>>> method return value constraint to a getter-style method, that is not
>>> evaluated when Validator.validate(object) is executed but after the
>>> method itself has been invoked? In OVal you have to explicitely add the
>>> @IsInvariant annotation to getter methods if their constraints should be
>>> evaluated too when Validator.validate(object) is executed. If so, OVal
>>> will invoke the getter and test the returned value against the
>>> constraints specified.
>>
>> Personally I'd say getters are methods such as any other methods, too.
>> So if a getter method is invoked one some bean generally qualifying
>> for method validation (however that is decided by the method
>> validation integration layer) the method's constraints should be
>> validated in the same way as any other method constraints. If the bean
>> is validated using Validator#validate(), the getter method's
>> constraints should be handled as property constraints as it's the case
>> today IMO.
>
> @IsInvariant is not much different from a group (though a bit more elegant). I don't think we should add something explicit in the spec to address this problem as we already can solve it with groups.
> Note that getters are not like ordinary methods, they are (by convention) Java properties and that's exactly what validator.validate processes (properties).

Yes, getters are considered as properties for standard bean validation
(Validator#validate()). But in the context of method validation I
would handle them as return value constraints as on any other method.

If I understand correctly, @IsInvariant as described above would be
breaking with the current spec behavior as it is needed to explicitly
enable a constraint on a getter for property validation, which is in
BV the case by default.

Using groups for cases, where a getter's constraints should be handled
different for property and method validation seems reasonable to me,
too.

An additional idea would be some option to apply a getter's
constraints also as method parameter constraints on the corresponding
setter. So if method validation for that bean is enabled, illegal
values couldn't be set at all. Would that be useful?

> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev