On 12 Jan 2017, at 19:45, Matt Benson <mbenson@apache.org> wrote:

> 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.

Do you mean?

@ConstraintAppliesTo(target=WRAPPED_VALUE, constraintTypes=Min.class)
@Min(3)
List<String> nicknames;

This approach cannot cover a case were the Min constraint it used one for the container and one for the wrapped value.

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.

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.

But it makes me think that we sorta addresssed a similar class of problem with groups.
I haven’t explored at all but could we something similar by subverting groups. Let’s define two special groups: OnContainer OnWrappedValue

@Min(value3, groups=OnWrappedValue.class)
List<String> nicknames;
// note that these examples are simplifications and should really be written List<@Min String> nicknames;
// but pretend we have a subclass of List<String> with no way to put a TYPE_USE constraint

The idea is kind of cute (for lack of a better word), but doesn't this complicate or prevent "normal" use of validation groups?

Right, it needs to be explored enough to qualify or be rejected.

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.

 

This proposal would not address the case of multiple nestsed containers List<List<String>>

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.

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.

Plus the example you give is just bad practice and illogical to quote Spok.

@Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<String>>

If you can plance constraints where you want, place then where they are the more natural and in this case the example is rewritten

@Size(min=5) List<@Size(min=3) List<@Size(min=3) String>>

The problema rises when you have class Matrix extends List<List<String>> {}

You have no place to put @Size(min=3) and @Size(min=24)

@Size(min=5)

@Size(min=3) //I want to be in the inner list

@Size(min=24) // I want to be in the most inner wrapped element

Matrix matrix;

TODO: I think I’m fine with not supporting such case and support #8 personally.

> 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.

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,.

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:

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>

Your understanding is correct, to validate the properties of Address, you need the @Valid annotation.

What the question 7 is about though is a bit different, I think (I’m confused now too :) )

Assume the following container class

class Tuple<T1,T2> {

  @NotNull

  T1 getT1();

  

  @Min(3)

  getSize();

   ...

}

Does the following validate that Integer is not null, does it validate that tuple size is at least 3?

Tuple<@Min(1) Integer, @Email String> tuple;

Is that a fair understanding of the question Gunnar ?

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev