I am open for discussion on this one. I have considered your approach but a couple of
things made me shy away from it:
- the lack of symmetry is fishy: granted that's not an argument and our inheritance is
not either in that regard
- if the inner method returns an unexpected result, interceptors / decorators might
stumble upon it
- an unexpected result should probably rollback the transaction just like an unexpected
parameter does
But in the end it boils down to this question: should we validate the inner method or
should we validate the client calling? Depending on that the interceptor moves.
We cannot realistically ask for two interceptions, one first and one last. Also, the specs
can't really protect people from doing really really bad things with interceptors so I
see the param / return value modifications as an edge-ish case.
On 27 févr. 2012, at 08:31, 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(a)hibernate.org>:
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev