I'd lean towards #1 too, for broadly the same reasons Hardy states. Freeing the method author from even having to consider the effect of interceptors seems like a "good thing" to me.


On 27 February 2012 08:52, Hardy Ferentschik <hardy@hibernate.org> wrote:

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


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