<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-04-01 12:56 GMT+02:00 Guillaume Smet <span dir="ltr">&lt;<a href="mailto:guillaume.smet@gmail.com" target="_blank">guillaume.smet@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Sat, Mar 31, 2018 at 2:19 PM, Gunnar Morling <span dir="ltr">&lt;<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>&gt;</span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><ul><ul><li>If more than one are marked with @UnwrapByDefault, a ConstraintDeclarationException is raised.</li></ul></ul></div></div></div></blockquote></span>I don&#39;t think we can or should do this, instead no extractor should be applied in this case. It&#39;d contradict quite clearly the spec&#39;s wording &quot;Otherwise, no value extractor is applied.&quot; Also the idea was that implicitly applied extractors should be applied implicitly if it&#39;s doable unambiguously, but they shouldn&#39;t cause any sort of configuration exception otherwise.</div></div></div></blockquote><div><br></div></span><div>Yes, I&#39;m stating that the spec is incorrect here and should be corrected.</div></div></div></div></blockquote><div><br></div><div>We quite clearly say that an exception is raised, so we cannot really change that in the spec.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>In all the other cases when we have competing value extractors, we throw an error. Why not in this case?</div></div></div></div></blockquote><div><br></div><div>The thinking was that *implicit* unwrapping should only be done if unambiguously possible. I.e. this implicit process shouldn&#39;t cause a configuration exception if it cannot be performed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Typically, you would have your constraints applied on the container elements, then you add another value extractor, and your constraints are then applied silently to the container instead of the container elements. That sounds like the wrong approach.</div></div></div></div></blockquote><div><br></div><div>I think that&#39;s just the nature of implicit application of extractors. You also could say &quot;you&#39;ve applied constraints to the container, then you add a value extractor, and your constraints are then applied silently to the container elements&quot;. We went this route to make it comfortable (no Unwrap payload needed) to apply constraints to non-generic wrappers such as OptionalInt.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- </div><div>Guillaume</div></font></span></div><br></div></div>
<br>______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br></blockquote></div><br></div></div>