<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 13, 2017 at 2:04 AM, Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On 12 Jan 2017, at 19:45, Matt Benson <<a href="mailto:mbenson@apache.org" target="_blank">mbenson@apache.org</a>> wrote:</div><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="m_4550387065947686565gmail-">> 2. Should @ConstraintsApplyTo be usable per-constraint?<br>> Doing such seems like it could be a bit clumsy, but it might be okay if @ConstraintsApplyTo were repeatable and included Class<? extends Annotation>[] constraintTypes() default {} element which, if non-empty, could differentiate which constraints applied to the wrapper vs. the extracted value.<br><br></span>Do you mean?<br><br>@ConstraintAppliesTo(target=WR<wbr>APPED_VALUE, constraintTypes=Min.class)<br>@Min(3)<br>List<String> nicknames;<br><br>This approach cannot cover a case were the Min constraint it used one for the container and one for the wrapped value.<br></blockquote><div><br></div><div>That is what I was postulating, yes. Min might not be the best example. NotNull might be a better example of a constraint that one would want to apply both to the wrapper and the extracted value.</div></div></div></div></div></blockquote><div><br></div></span><div>In this case, let’s use @Size whbich would make the example valid. A list of at least 3 elements vs a nickname of at least 3 characters.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>But it makes me think that we sorta addresssed a similar class of problem with groups.<br>I haven’t explored at all but could we something similar by subverting groups. Let’s define two special groups: OnContainer OnWrappedValue<br><br>@Min(value3, groups=OnWrappedValue.class)<br>List<String> nicknames;<br>// note that these examples are simplifications and should really be written List<@Min String> nicknames;<br>// but pretend we have a subclass of List<String> with no way to put a TYPE_USE constraint<br><br></blockquote><div><br></div><div>The idea is kind of cute (for lack of a better word), but doesn't this complicate or prevent "normal" use of validation groups?</div></div></div></div></div></blockquote><div><br></div></span><div>Right, it needs to be explored enough to qualify or be rejected.</div><div>I * think* that since groups are additive in nature and if we disallow people to use these special groups in sequences and other groups, they would not interfere at all.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">This proposal would not address the case of multiple nestsed containers List<List<String>><br><span class="m_4550387065947686565gmail-"><br></span></blockquote><div><br></div><div>I agree that specifying WRAPPED_VALUE per-property is ambiguous for List<List<String>>. Maybe that is an argument against allowing #8. What if the rule were that @ConstraintsApplyTo(WRAPPED_<wbr>VALUE) is valid on TypeExtractor class definitions, while @ConstraintsApplyTo(ANNOTATED_<wbr>ELEMENT) is valid elsewhere, serving only to override the behavior specified by the extractor? Then you could have @Size(min=5) @ConstraintsApplyTo(ANNOTATED_<wbr>ELEMENT) List<@Size(min=3) @ConstraintsApplyTo(ANNOTATED_<wbr>ELEMENT) List<String>> . This still doesn't solve #2, but I think the problems are orthogonal.</div></div></div></div></div></blockquote><div><br></div></span><div>I suppose this assumes that most if not all extractor would have @ConstraintsApplyTo(WRAPPED_<wbr>VALUE) set so that a user has the option to do annotated element vs wrapped value on site. That would be a bad default for iterable and break BV 1.1 semantic in a backward incompatible way (without @ConstraintsApplyTo on site, my @Min annotation would not longer validate the container size but what’s inside.</div><div><br></div><div>Plus the example you give is just bad practice and illogical to quote Spok.</div></div></div></blockquote><div><br></div><div>Okay, you're right: List was a bad example, since its type parameter should be a "plain" extractor. So let's use Optional, whose extractor is annotated such that constraints apply to wrapped values by default:</div><div><br></div><div>@NotNull @ConstraintsApplyTo(ANNOTATED_ELEMENT) Optional<@NotNull @ConstraintsApplyTo(ANNOTATED_ELEMENT) Optional<Foo>> optOptFoo;</div><div><br></div><div>This invokes question #2, whether there would be a way at the "top" level to declare that neither the outer Optional nor the inner Optional may be null. If so, the above example could be rewritten using that mechanism.</div><div><br></div><div>Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div><br></div><div>@Size(min=5) @ConstraintsApplyTo(ANNOTATED_<wbr>ELEMENT) List<@Size(min=3) @<wbr>ConstraintsApplyTo(ANNOTATED_<wbr>ELEMENT) List<String>></div><div><br></div></span><div>If you can plance constraints where you want, place then where they are the more natural and in this case the example is rewritten</div><div><br></div><div>@Size(min=5) List<@Size(min=3) List<@Size(min=3) String>></div><div><br></div><div>The problema rises when you have class Matrix extends List<List<String>> {}</div><div>You have no place to put @Size(min=3) and @Size(min=24)</div><div><br></div><div>@Size(min=5)</div><div>@Size(min=3) //I want to be in the inner list</div><div>@Size(min=24) // I want to be in the most inner wrapped element</div><div>Matrix matrix;</div><div><br></div><div>TODO: I think I’m fine with not supporting such case and support #8 personally.</div><span class=""><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="m_4550387065947686565gmail-"><br>> 7. Should the presence of type argument constraints alone trigger nested validation?<br>> I can appreciate the sense of the consistency argument to requiring @Valid, but in practice it seems reasonable to me that @Valid be implied. It probably would be much simpler to require @Valid from an implementation perspective, however.<br><br></span>I personally am a bit reluctant. Do we really think that this is the default behavior people will want? Because you cannot negate a @Valid today so that’s a definitive decision. It seems to be that many containers are not beans per se and don’t want their properties to be validated, just the extacted stuff,.<br><br></blockquote><div>Are you saying that type argument constraints will be validated using extraction, but that only validation of the Map object *itself* would depend on @Valid to trigger validation of Map values per BV 1.x? So if Address had validation metadata, you could have:<br></div><div><br></div><div>Map<AddressType, @NotNull Address></div><div><br></div><div>And BV would validate that the values were non-null, but would not invoke Address validation without @Valid on the Map (BV 1.x) or on the Address type parameter? That makes sense to me. You could then combine:</div><div><br></div><div>Map<AddressType, @NotNull @Valid Address></div></div></div></div></blockquote><div><br></div></span><div>Your understanding is correct, to validate the properties of Address, you need the @Valid annotation.</div><div><br></div><div>What the question 7 is about though is a bit different, I think (I’m confused now too :) )</div><div><br></div><div>Assume the following container class</div><div><br></div><div>class Tuple<T1,T2> {</div><div><br></div><div> @NotNull</div><div> T1 getT1();</div><div> </div><div> @Min(3)</div><div> getSize();</div><div><br></div><div> ...</div><div>}</div><div><br></div><div>Does the following validate that Integer is not null, does it validate that tuple size is at least 3?</div><div><br></div><div>Tuple<@Min(1) Integer, @Email <wbr>String> tuple;</div><div><br></div><div>Is that a fair understanding of the question Gunnar ?</div></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>