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.<div>
<br></div><div>regards,</div><div>gerhard</div><div><br></div><div><br></div><div><br><div class="gmail_quote">2012/2/28 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Emmanuel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 28 févr. 2012, at 00:28, Michael Nascimento wrote:<br>
<br>
> Ok, let's complicate matters a little bit:<br>
><br>
> If a bean is exposed through an interface and therefore constraints<br>
> are applied to the implementation, obviously parameter validation<br>
> should happen right before invoking the method and return validation<br>
> should happen right after return. In this case, validation constraints<br>
> are completely opaque for the original caller and certainly they are<br>
> not part of the API.<br>
><br>
> If a bean is exposed *directly* to the caller, constraints are part of<br>
> the API exposed to the caller. They are part of the contract pretty<br>
> much like possible thrown checked exceptions and all, so it would make<br>
> more sense to validate parameters right after the caller invokes it<br>
> and validate the return value right before delivering it to the<br>
> caller. Then, the API does what it says.<br>
><br>
> Does this different behaviour sound complicated? Yes, but this is<br>
> technically the correct thing to do if you think about validation<br>
> being part of the API or not. As cumbersome as it seems, it is<br>
> possible to implement it using CDI since it allows one to get the<br>
> exact InjectionTarget and check for the API rule above. Should it be<br>
> done that way? That is open to discussion, but I am pretty sure other<br>
> people will reason it the way I just did.<br>
><br>
> Regards,<br>
> Michael<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div>