<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 12 Jan 2017, at 19:45, Matt Benson <<a href="mailto:mbenson@apache.org" class="">mbenson@apache.org</a>> wrote:</div><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><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="gmail-">> 2. Should @ConstraintsApplyTo be usable per-constraint?<br class="">> 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 class=""><br class=""></span>Do you mean?<br class=""><br class="">@ConstraintAppliesTo(target=<wbr class="">WRAPPED_VALUE, constraintTypes=Min.class)<br class="">@Min(3)<br class="">List<String> nicknames;<br class=""><br class="">This approach cannot cover a case were the Min constraint it used one for the container and one for the wrapped value.<br class=""></blockquote><div class=""><br class=""></div><div class="">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 class=""></div><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><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><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 class="">But it makes me think that we sorta addresssed a similar class of problem with groups.<br class="">I haven’t explored at all but could we something similar by subverting groups. Let’s define two special groups: OnContainer OnWrappedValue<br class=""><br class="">@Min(value3, groups=OnWrappedValue.class)<br class="">List<String> nicknames;<br class="">// note that these examples are simplifications and should really be written List<@Min String> nicknames;<br class="">// but pretend we have a subclass of List<String> with no way to put a TYPE_USE constraint<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">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 class=""></div><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><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </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 class=""><span class="gmail-"><br class=""></span></blockquote><div class=""><br class=""></div><div class="">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_VALUE) is valid on TypeExtractor class definitions, while @ConstraintsApplyTo(ANNOTATED_ELEMENT) is valid elsewhere, serving only to override the behavior specified by the extractor? Then you could have @Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<String>> . This still doesn't solve #2, but I think the problems are orthogonal.</div></div></div></div></div></blockquote><div><br class=""></div><div>I suppose this assumes that most if not all extractor would have @ConstraintsApplyTo(WRAPPED_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 class=""></div><div>Plus the example you give is just bad practice and illogical to quote Spok.</div><div><br class=""></div><div>@Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<String>></div><div><br class=""></div><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 class=""></div><div>@Size(min=5) List<@Size(min=3) List<@Size(min=3) String>></div><div><br class=""></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 class=""></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 class=""></div><div>TODO: I think I’m fine with not supporting such case and support #8 personally.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><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="gmail-"><br class="">> 7. Should the presence of type argument constraints alone trigger nested validation?<br class="">> 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 class=""><br class=""></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 class=""><br class=""></blockquote><div class="">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 class=""></div><div class=""><br class=""></div><div class="">Map<AddressType, @NotNull Address></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Map<AddressType, @NotNull @Valid Address></div></div></div></div></blockquote><div><br class=""></div><div>Your understanding is correct, to validate the properties of Address, you need the @Valid annotation.</div><div><br class=""></div><div>What the question 7 is about though is a bit different, I think (I’m confused now too :) )</div><div><br class=""></div><div>Assume the following container class</div><div><br class=""></div><div>class Tuple<T1,T2> {</div><div><br class=""></div><div> @NotNull</div><div> T1 getT1();</div><div> </div><div> @Min(3)</div><div> getSize();</div><div><br class=""></div><div> ...</div><div>}</div><div><br class=""></div><div>Does the following validate that Integer is not null, does it validate that tuple size is at least 3?</div><div><br class=""></div><div>Tuple<@Min(1) Integer, @Email String> tuple;</div><div><br class=""></div><div>Is that a fair understanding of the question Gunnar ?</div></div></body></html>