1:31 a.m.
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>:
2:52 a.m.
New subject: When is a method validated
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(a)hibernate.org>:
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:04 a.m.
New subject: When is a method validated
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
3:05 a.m.
New subject: When is a method validated
Good analysis and sum up.
On 27 févr. 2012, at 09:52, Hardy Ferentschik wrote:
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(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
3:13 a.m.
New subject: When is a method validated
Hi
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.
Rich
On 27 February 2012 08:52, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
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(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
6:09 a.m.
New subject: When is a method validated
I go for method centric validation. Constraint annotations on interfaces
and methods are contracts for their respective implementations not
depending on what interceptors are wrapping them. Runtime environments
supporting interceptors may additionally provide configuration options
that also support client centric view and thus ensure that interceptors
modifying input/output values satisfy these contracts too.
Seb
On 27.02.2012 09:52, Hardy Ferentschik wrote:
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(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
11:52 a.m.
New subject: When is a method validated
- 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
5:28 p.m.
New subject: When is a method validated
Ok, let's complicate matters a little bit:
If a bean is exposed through an interface and therefore constraints
are applied to the implementation, obviously parameter validation
should happen right before invoking the method and return validation
should happen right after return. In this case, validation constraints
are completely opaque for the original caller and certainly they are
not part of the API.
If a bean is exposed *directly* to the caller, constraints are part of
the API exposed to the caller. They are part of the contract pretty
much like possible thrown checked exceptions and all, so it would make
more sense to validate parameters right after the caller invokes it
and validate the return value right before delivering it to the
caller. Then, the API does what it says.
Does this different behaviour sound complicated? Yes, but this is
technically the correct thing to do if you think about validation
being part of the API or not. As cumbersome as it seems, it is
possible to implement it using CDI since it allows one to get the
exact InjectionTarget and check for the API rule above. Should it be
done that way? That is open to discussion, but I am pretty sure other
people will reason it the way I just did.
Regards,
Michael
3:27 a.m.
New subject: When is a method validated
I personally feel uneasy about having the behavior change depending on how visible
annotations are to the client even though I understand the reasoning. As I said,
interceptor messing around parameter and return values are not very common and one could
clearly put interceptors not complying with the constraints under the programming error. I
am reluctant to introduce an option to alter the behavior.
That being said. Java EE 7 plans on making interceptors configuration generic. So it's
likely that one person will be able to reorder its interceptors or even write its own.
Emmanuel
On 28 févr. 2012, at 00:28, Michael Nascimento wrote:
Ok, let's complicate matters a little bit:
If a bean is exposed through an interface and therefore constraints
are applied to the implementation, obviously parameter validation
should happen right before invoking the method and return validation
should happen right after return. In this case, validation constraints
are completely opaque for the original caller and certainly they are
not part of the API.
If a bean is exposed *directly* to the caller, constraints are part of
the API exposed to the caller. They are part of the contract pretty
much like possible thrown checked exceptions and all, so it would make
more sense to validate parameters right after the caller invokes it
and validate the return value right before delivering it to the
caller. Then, the API does what it says.
Does this different behaviour sound complicated? Yes, but this is
technically the correct thing to do if you think about validation
being part of the API or not. As cumbersome as it seems, it is
possible to implement it using CDI since it allows one to get the
exact InjectionTarget and check for the API rule above. Should it be
done that way? That is open to discussion, but I am pretty sure other
people will reason it the way I just did.
Regards,
Michael
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:13 p.m.
New subject: When is a method validated
since it's possible to define the order of cdi interceptors via the std.
beans.xml config and there are a lot of very different valid use-cases, i
would prefer one default behaviour and the possibility to specify a custom
order via the std. cdi config.
regards,
gerhard
2012/2/28 Emmanuel Bernard <emmanuel(a)hibernate.org>
I personally feel uneasy about having the behavior change depending
on how
visible annotations are to the client even though I understand the
reasoning. As I said, interceptor messing around parameter and return
values are not very common and one could clearly put interceptors not
complying with the constraints under the programming error. I am reluctant
to introduce an option to alter the behavior.
That being said. Java EE 7 plans on making interceptors configuration
generic. So it's likely that one person will be able to reorder its
interceptors or even write its own.
Emmanuel
On 28 févr. 2012, at 00:28, Michael Nascimento wrote:
> Ok, let's complicate matters a little bit:
>
> If a bean is exposed through an interface and therefore constraints
> are applied to the implementation, obviously parameter validation
> should happen right before invoking the method and return validation
> should happen right after return. In this case, validation constraints
> are completely opaque for the original caller and certainly they are
> not part of the API.
>
> If a bean is exposed *directly* to the caller, constraints are part of
> the API exposed to the caller. They are part of the contract pretty
> much like possible thrown checked exceptions and all, so it would make
> more sense to validate parameters right after the caller invokes it
> and validate the return value right before delivering it to the
> caller. Then, the API does what it says.
>
> Does this different behaviour sound complicated? Yes, but this is
> technically the correct thing to do if you think about validation
> being part of the API or not. As cumbersome as it seems, it is
> possible to implement it using CDI since it allows one to get the
> exact InjectionTarget and check for the API rule above. Should it be
> done that way? That is open to discussion, but I am pretty sure other
> people will reason it the way I just did.
>
> Regards,
> Michael
> _______________________________________________
> 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
4602
days inactive
4605
days old
beanvalidation-dev@lists.jboss.org
9 comments
7 participants
participants (7)
-
Emmanuel Bernard -
Gerhard Petracek -
Gunnar Morling -
Hardy Ferentschik -
Michael Nascimento -
Rich Midwinter -
Sebastian Thomschke