On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers@me.com> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev