Re: [bv-dev] Constraint on non generic types (was Re: Support for constraints on container values (e.g. Collection<@Email String>))

== Constraint on non parameterized containers I am liking option 3 less and less and as far as I can remember, it does

identified use case. Who is wanting to support that usage, vs restrict

parameterized containers?

On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers(a)me.com&gt; wrote: In addition I think that simply adding a constraints annotation to the generic type is wrong. All examples that we have mentioned are just perfect examples in that the generic type defines the content. Let’s say we have a class like this: public abstract class ConvertableInteger<V> { private int value; public void setValue(int value) { this.value = value; } public int getValue() { return value; } public abstract V getConvertedValue(); } If you want to validate an instance of this class you normally want to validate the integer and not the converted value: private ConvertableInteger<@Min(2_000_000) Date> myValue; Such an expression looks like if you want to validate a Date object. In this case the better solution would be something like this: @Min(2_000_000) private ConvertableInteger<Date> myValue; And now we end in 2 different ways how we annotation value wrappers: private CachableValue<@NotEmpty String> myCachedValue; @Min(2_000_000) private ConvertableInteger<Date> myIntegerValue; First off, your specific example does not work as is as the class is abstract. You would need an explicit subclass (e.g. DateConvertableInteger extends ConvertableInteger<Date>). And in that situation, The more natural BV approach would be to do this: public class DateConvertableInteger extend ConvertableInteger<Date> { @Min(@2_000_000) public int getValue() { return value; } @NotEmpty public Date getConvertedValue(); } class SomeClass { @Valid private StringConvertableInteger myValue; } == overriding constraint declarations Now if you want a way to override the constraints of an embedded (@Valid) object (graph), then I think that is a different subject that we can try and address. JPA for example has the notion of @AttributeOverride. It is more complicated in the case of Bean Validation as we would need to override actual annotations. Not sure how to express that for now. Do we think that it is a valid and important requirement? To clarify, here is what is required public class Embeddable { @NotEmpty String foo; } public class Entity { @Valid @Override(path=“foo”, constraints=@Min(3)) // note that this is not valid Java syntax Embeddable embeddable; } == Constraint on non parameterized containers That raises another question, the proposal allows to to three things: - apply constraints on a type use generic declaration(*): Collection<@NotEmpty String> foo; - apply constraints on specialized generic parameters (*): @Pattern(…) StringProperty prop; //where StringProperty extends Property<String> - apply constraints on container with no generic: @Min(3) IntegerContainer prop; // where class IntegerContainer{ Integer value; } i.e. no generic (*) I don’t know the actual proper names so sorry if I butchered notions I am liking option 3 less and less and as far as I can remember, it does not rely on an explicitly identified use case. Who is wanting to support that usage, vs restrict the container feature to parameterized containers? I’m not sure I was all that clear, so please ask any question if you have any doubt. Emmanuel _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev