- an unexpected result should probably rollback the transaction just
like an unexpected parameter does
Yep, that's a really good point. So it should run when the TX is still
running. I'm still a bit concerned about interceptors modifying return
values, but comparing both aspects, rolling back transactions upon
validation failures seems more important to me. And as Hardy said,
interceptors should just not modify method return values.
--Gunnar
2012/2/27 Emmanuel Bernard <emmanuel(a)hibernate.org>:
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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev