I generally like this; I think the proposal is in quite good shape. My reactions to the open questions: 1. Should nested containers be supported? Given the Optional<List<@Email String>> example, it's probably a good idea (certainly it adds some complexity, but anything worth doing is worth doing right, as the saying goes). 2. Should @ConstraintsApplyTo be usable per-constraint? 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. 3. Should @ConstraintsApplyTo also be used for tagging extractors triggering "auto-extraction"? I'm not sure I understand this question. Is this referring to classpath scanning, or "inline" specification of extractors? In either case a separate annotation might be warranted, particularly if the annotation is expanded for other reasons (see #2). 4. Should a path node be added for type argument constraints of Optional and similar types? I don't personally feel this is necessary, but I wouldn't oppose it if others strongly desired it. 5. Should value extractors be discoverable via ServiceLoader? I would personally really like to see this be possible. WRT being able to override these, it seems simple enough that value extractors registered programmatically or in validation.xml could preempt any discovered via ServiceLoader. 6. What to return from PropertyDescriptor#getElementClass() if field type does not match method RT? The Javadoc of PropertyDescriptor references "Java Beans." Java Bean properties are defined by method signatures rather than fields, so it seems an easy decision to choose the method RT over the field signature. 7. Should the presence of type argument constraints alone trigger nested validation? 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. 8. The core question seems to me to be whether there should be multiple valid mechanisms for specifying constraints on wrapped elements. Since it's necessary to support the inverse for wrapped elements of non-parameterized types, the effort required to support this is probably similar to that required to disallow it. 9. Should we allow extractors to be defined for specific parameterized types? It's tempting to support this, extends bounds and all, just to feel that the feature is as complete as possible. At the same time I can't make a compelling case why such a feature would really be *necessary*. This suggests support for things like: class FooToBarMapValueExtractor implements ValueExtractor<Map<? extends Foo, @ExtractedValue ? extends Bar>> . In this case it might even be reasonable to equivalently support: class FToBMapValueExtractor<F extends Foo, B extends Bar> implements ValueExtractor<Map<F, @ExtractedValue B>> (i.e. BV would not care whether the bounds are specified on the type parameter of the extractor class or on the argument to the wrapper type). Not to say that these might not be valid use cases, but we should enter any such complexity with our eyes open, to be sure. 10. I have no suggestions for alternatives to "type argument constraints." "Type constraints" suggests the argument to a type parameter itself. "Type use constraints" is fine with me, though. If people don't know, they can learn. ;) 11. No input on this from me (for now, anyway). 12. I don't see why it would be necessary for an extractor to refer to a parameter from a super type. The super type parameter can(/should) be mapped to a type parameter from the extractor type. Or am I missing something? 13/14. I am in favor of the variant proposals that would permit the type parameter to be included as part of a Path node. Additional notes: * I think we ought to consider whether to provide ValueReceiver methods that omit the nodeName parameter rather than having ValueExtractor implementations pass null. We could potentially then require non-blank values when the nodeName-bearing method variants are called. This would make the API more explicit and we're not talking about an interface that will conceivably have a lot of implementations. * Some of the features that might come under debate, e.g. ServiceLoader-discovered ValueExtractors, could be enabled via implementation-specific configuration parameters or e.g. CDI extensions, etc., if the community can't reach a consensus or decides to omit them. Matt On Fri, Jan 6, 2017 at 9:43 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote:

On Thu, Jan 12, 2017 at 9:15 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: 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. The idea is kind of cute (for lack of a better word), but doesn't this complicate or prevent "normal" use of validation groups? 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. as outlined in the current draft? Then my answer is yes. 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: Map<AddressType, @NotNull Address> 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: Map<AddressType, @NotNull @Valid Address> Matt

Pretend this sentence was never in my email.

Right that’s Gunnar’s argument, it would feel weird to disallow it. My slight preference would be to disallow it for it’s “wrongness” (it confuses code more than clarifying it). The feature got introduced at a time where we did need that feature for now deprecated reasons. But there is still a theoretical situation. I have a Map value extractor and a HashMap value extractor. Somehow the HashMap value extractor uses HashMap specific methods to do the extraction job in a more efficient way. But we have not found a concrete example of that problem.