<div dir="ltr"><div>Hi,</div><div><br></div>To give some background: the idea was to let integration frameworks decide which executables should be validated to allow for consistency with their own rules for interceptor enablement and request processing; e.g. JAX-RS validates getter-style resource methods by default, or a DI framework might have its own annotation for controlling validation or descriptor format for registering interceptors.<div class="gmail_extra">
<br></div><div class="gmail_extra">Based on that, @ValidateOnExecution (and the settings in XML) is provided as the *recommended* way of controlling executable validation but its not obligatory: &quot;This section expresses the behavior that integration with
      interception frameworks should follow. Any deviation should be
      considered with care as it will surprise Bean Validation users.&quot;</div><div class="gmail_extra"><br></div><div class="gmail_extra">That being said, I agree that adding a facility for retrieving these settings via the BV API makes sense to make life easier for those integrators wishing to adhere to the BV behavior; integrators with deriving behavior could still use this API as input for their evaluation.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">--Gunnar</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/26 Emmanuel Bernard <span dir="ltr">&lt;<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>&gt;</span><br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I will let Hardy and Gunnar answer that one, this has been discussed a lot and some arguments they provided lead to delegate the rules implementations to the integration framework.<br>


<div><div><br>
On 25 juil. 2013, at 22:55, Gerhard Petracek &lt;<a href="mailto:gerhard.petracek@gmail.com" target="_blank">gerhard.petracek@gmail.com</a>&gt; wrote:<br>
<br>
&gt; hi @ all,<br>
&gt;<br>
&gt; currently every framework which needs to integrate (bv based) method-validation has to implement the rules specified for @ValidateOnExecution itself.<br>
&gt; there is no method in the api for delegating the evaluation to the bv-implementation (and everything passed to ExecutableValidator gets validated<br>
&gt; independent of the xml based or annotation based config).<br>
&gt;<br>
&gt; it isn&#39;t just a higher effort for such frameworks, it (already) leads to inconsistencies across frameworks.<br>
&gt; -&gt; imo it should be one of the first topics for bv.next.<br>
&gt;<br>
&gt; regards,<br>
&gt; gerhard<br>
</div></div>&gt; _______________________________________________<br>
&gt; beanvalidation-dev mailing list<br>
&gt; <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">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>
</blockquote></div><br></div></div>