As far as this goes, I agree that it makes sense to be flexible and consistent with earlier specification versions; i.e. to permit annotation of type parameters both on fields and their associated accessor methods. With regard to the mechanism used for reaching the validated contained values, my feeling is that some combination of the proposals at [1] is correct (i.e. the explicitness of the original proposal plus the aspect of your proposal to combine the extracted value with the associated path/node). It would probably also be helpful to provide an annotation-based shorthand for class developers to mark the extracted elements of custom container types without having to write an extractor implementation (which ties into my otherwise clueless response on an earlier thread ;) ). Matt 1.http://beanvalidation.org/proposals/BVAL-508/ On Dec 2, 2016 9:20 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; wrote: > Hi, > > As you may have seen, Emmanuel started a survey on how people would like > to use type-level constraints in Bean Validation: http://beanvalidat > ion.org/news/2016/11/23/survey-constraints-and-parameterized-type/ > > While we are waiting for some more replies to that one, I started with a > PoC implementation of the value extractor idea in the reference > implementation in order to get a better feeling for it, it's limitations, > open questions etc.: https://github.com/hibernate/h > ibernate-validator/pull/592 > > One thing we started to wonder is whether it should be allowed to put > type-level constraints to a field *and* the corresponding property getter > at the same time: > > private List<@NotBlank String> strings; > > public List<@Pattern(regexp="...") String> getStrings() { return > strings; } > > My first inclination was to say that it should be supported (as you can > put regular constraints to a field and its getter). A challenge is how to > obtain the values for constraint validation. In the spirit of BV 1 we'd > have to iterate the values directly from the field for evaluating the > @NotBlank constraint and a second time through the getter for @Pattern > validation. That's a potential performance issue of course. > > What do others think? > > Thanks, > > --Gunnar > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev