[bv-dev] When is a method validated

[Sebastian Thomschke]

I go for method centric validation. Constraint annotations on interfaces 
and methods are contracts for their respective implementations not 
depending on what interceptors are wrapping them. Runtime environments 
supporting interceptors may additionally provide configuration options 
that also support client centric view and thus ensure that interceptors 
modifying input/output values satisfy these contracts too.

Seb

On 27.02.2012 09:52, Hardy Ferentschik wrote:
> Hi,
>
> I think there are really two view points in this case.
>
> 1. method centric (Emmanuel's suggestion)
> The parameters are validated at the moment they are passed to the method (after all interceptors did their work) and the return value
> gets validated as returned by the method. This could lead to the fact that, if there are interceptors which modify the return value before
> passing it back to the client, return value constraints could be broken (e.g. return null for a non null value)
>
> 2. client centric (Gunnar's suggestion)
> The parameter validation is again last in the interceptor chain. In this case, however, the return value would be validated after the interceptors
> are run. The benefit is that return value constraints gets validated just before they are returned to the client.
>
> > From a design by contract point of view I would expect the behavior of #1. Method level validation is about what is passed to a method and
> directly returned by it. There should be no consideration for interceptors.
>
> #2 seems to make more sense from a client perspective, but really which interceptor would modify a return value? Interceptors are good for many
> things, but I definitely would not expect them to change the return value (at most  to throw an exception).
>
> For that reason and the fact that #1 is symmetric I vote for #1
>
> --Hardy
>
>
>
> On Feb 27, 2012, at 8:31 AM, Gunnar Morling wrote:
>
>> Hi,
>>
>> I agree with respect to parameter validation.
>>
>> But shouldn't the validation interceptor also run last for return value validation, that is after all interceptors potentially modifying the return value? That way both contracts (pre- and postconditions) are enforced as closest to their clients (method implementation respectively method caller) as possible. Other interceptors generally couldn't rely on the correctness of parameters/return values.
>>
>> The order would then look like that:
>>
>> ...
>> validate parameters
>> method call
>> ...
>> validate return value
>>
>> --Gunnar
>>
>> Am 26.02.2012 19:28 schrieb "Emmanuel Bernard"<emmanuel at hibernate.org>:
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev