[bv-dev] When is a method validated

[Emmanuel Bernard]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120227/ba025581/attachment.html