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@hibernate.org>:
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev