From guillaume.smet at gmail.com  Wed Apr 12 10:16:40 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 12 Apr 2017 16:16:40 +0200
Subject: [bv-dev] Conflict issue with value extraction and JavaFX collection
	types
Message-ID: <CALt0+o_C-_upB2+X9n70gTX3AJV59UvVEgFORsjPgbwnLrv1pA@mail.gmail.com>

Hi,

We are refining the value extraction work and one of the remaining tasks is
to throw a proper exception if we have ValueExtractors defined in parallel
hierarchies for a given type.

This led to discovering the below issue with the JavaFX collection types.

Let's take the ListProperty example (we have the same issue with Set and
Map): ListProperty inherits from ObservableValue and from List.

For now, it uses (by chance) the ObservableValue extractor which unwraps
the value by default. So basically:
@NotNull
private ListProperty<String> listProperty = new
ReadOnlyListWrapper<String>( null );
will return a violation.

With the new conflict detection, it will throw an exception as it's unable
to find ONE most specific ValueExtractor as there are 2 valid candidates:
ObservableValueValueExtractor and ListValueExtractor.

If we want to solve the conflict, we need to introduce a specific
ValueExtractor for ListProperty and decide of its behavior.

We have 2 possibilities:
1/ consider ListProperty as an ObservableValue and thus simply unwrap the
list and validate the constraint against the list. In the above example,
@NotNull would then apply to the inner list. Same behavior as explained
above.
2/ consider ListProperty as a List. Thus the value extractor would iterate
over the element of the list. In the above case, it won't return a
violation. In the below example, the @NotNull would refer to listProperty
itself and the constraints on the elements of the list would be validated:
@NotNull
private ListProperty<@Size(min = 3) String> listProperty = new
ReadOnlyListWrapper<String>( null );

Gunnar and I are in favor of 2/ but it changes the current behavior as the
@NotNull would refer to the container instead of referring to the wrapped
value.

We would really like to have some feedback from people using JavaFX.

Thanks!

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170412/92999b1c/attachment-0001.html 

From gunnar at hibernate.org  Fri Apr 14 04:42:21 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 14 Apr 2017 10:42:21 +0200
Subject: [bv-dev] Road to Final
Message-ID: <CADGJaX_ep6988kPQFAKg57mbTX_7pD6LvVkGEfCjm+tgMgZhVA@mail.gmail.com>

Hi all,

As you know Bean Validation 2.0 is planned to be part of the Java EE 8
spec which should be released in July.

For that also BV needs to go to the Final Approval Ballot early in
July. This means we'll have to go to Public Draft soon, as this is
running for 30 days, followed by 2 weeks of Public Review Ballot by
the EC. So the Public Draft should start end of April, meaning I'll
have to submit the Public Draft soonish to the JCP.

I've planned to do so next weekend (April 23rd) so that JCP folks have
enough time to prepare it for publication. The most important thing
missing is to pull the container element validation feature from the
spec into the appendix. I'm working on this currently, you can expect
a PR for this mid next week.

If you have any thoughts on this or if there is anything else which
you think should be part of the Public Draft, please speak up (or send
in a PR) asap, as the clock is running.

Note that we can still do changes while the Public Review is running,
in this case a revised Public Draft can be posted on jcp.org. We can
use that to address some more smaller issues.

Thanks,

--Gunnar

From emmanuel at hibernate.org  Tue Apr 18 08:57:59 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 18 Apr 2017 14:57:59 +0200
Subject: [bv-dev] Conflict issue with value extraction and JavaFX
 collection types
In-Reply-To: <CALt0+o_C-_upB2+X9n70gTX3AJV59UvVEgFORsjPgbwnLrv1pA@mail.gmail.com>
References: <CALt0+o_C-_upB2+X9n70gTX3AJV59UvVEgFORsjPgbwnLrv1pA@mail.gmail.com>
Message-ID: <20170418125759.GC17322@hibernate.org>

I'm not using JavaFX but I would be in favor of 2. because it let's
people put a size constraint on the List.

Have you considered a blog post to get more feedback. Here people don't
use JavaFX or are shy.

On Wed 17-04-12 16:16, Guillaume Smet wrote:
>Hi,
>
>We are refining the value extraction work and one of the remaining tasks is
>to throw a proper exception if we have ValueExtractors defined in parallel
>hierarchies for a given type.
>
>This led to discovering the below issue with the JavaFX collection types.
>
>Let's take the ListProperty example (we have the same issue with Set and
>Map): ListProperty inherits from ObservableValue and from List.
>
>For now, it uses (by chance) the ObservableValue extractor which unwraps
>the value by default. So basically:
>@NotNull
>private ListProperty<String> listProperty = new
>ReadOnlyListWrapper<String>( null );
>will return a violation.
>
>With the new conflict detection, it will throw an exception as it's unable
>to find ONE most specific ValueExtractor as there are 2 valid candidates:
>ObservableValueValueExtractor and ListValueExtractor.
>
>If we want to solve the conflict, we need to introduce a specific
>ValueExtractor for ListProperty and decide of its behavior.
>
>We have 2 possibilities:
>1/ consider ListProperty as an ObservableValue and thus simply unwrap the
>list and validate the constraint against the list. In the above example,
>@NotNull would then apply to the inner list. Same behavior as explained
>above.
>2/ consider ListProperty as a List. Thus the value extractor would iterate
>over the element of the list. In the above case, it won't return a
>violation. In the below example, the @NotNull would refer to listProperty
>itself and the constraints on the elements of the list would be validated:
>@NotNull
>private ListProperty<@Size(min = 3) String> listProperty = new
>ReadOnlyListWrapper<String>( null );
>
>Gunnar and I are in favor of 2/ but it changes the current behavior as the
>@NotNull would refer to the container instead of referring to the wrapped
>value.
>
>We would really like to have some feedback from people using JavaFX.
>
>Thanks!
>
>-- 
>Guillaume

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


From gunnar at hibernate.org  Wed Apr 19 04:27:24 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 19 Apr 2017 10:27:24 +0200
Subject: [bv-dev] Container element validation for arrays
Message-ID: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>

Hi,

Guillaume made an important observation concerning the validation of
array elements. So far we envisioned to support this:

    String @Email [] emails;

That looks nice (provided that @Email supports TYPE_USE), only that
it's getting semantics of type annotations for arrays wrong.

As per the JLS [1], the @Email annotation here applies to the array
type String[], not the component type String. This example from the
JLS clarifies the intent:

    @C int @A [] @B [] f;

    "@A applies to the array type int[][], @B applies to its component
type int[],
    and @C applies to the element type int."

So according to that, our example would have to be:

    @Email String[] emails;

But obviously this conflicts with the existing semantics of applying
constraints to arrays (not their elements) in BV 1.1.

So based on that, I don't see a good way for supporting container
element constraints for arrays. Hence my suggestion is to not support
them in the BV 2.0 spec (the validation of container elements of
generic containers - List<@Email String> - is not affected). Specific
implementations may explore ways around it (e.g. specifying the target
via payload()) and we may revisit it in 2.1.

Any thoughts?

--Gunnar

[1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.4

From guillaume.smet at gmail.com  Wed Apr 19 06:28:05 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 19 Apr 2017 12:28:05 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
Message-ID: <CALt0+o9YA-QZK3i8T9n74zyLZYkJmyKUuD0oB31cttZq10w2Yg@mail.gmail.com>

Hi,

FWIW, the main issue with BV 1.1 compatibility is that BV 1.1 supports:
[Example 1]
@Size(min = 2)
private String[] array;

which was the way to write that the array should have a minimum length of 2
(and was perfectly valid if the @Size constraint does not have a TYPE_USE
target)

If we consider TYPE_USE support for arrays, according to the JLS, it should
in fact be written:
[Example 2]
private String @Size(min = 2) [] array;

And the main compatibility issue is that the meaning of [Example 1] would
not be compatible with the BV 1.1 behavior: it should mean that the String
inside the array must have a minimum length of  2.

See the class I used as a playground here:
https://github.com/gsmet/annotation-on-type-argument-array-bug/blob/master/src/main/java/org/hibernate/jdk/annotationontypeargumentarraybug/WrongAnnotationsReturnedForArrayTypeArgumentTest.java

-- 
Guillaume

On Wed, Apr 19, 2017 at 10:27 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> Guillaume made an important observation concerning the validation of
> array elements. So far we envisioned to support this:
>
>     String @Email [] emails;
>
> That looks nice (provided that @Email supports TYPE_USE), only that
> it's getting semantics of type annotations for arrays wrong.
>
> As per the JLS [1], the @Email annotation here applies to the array
> type String[], not the component type String. This example from the
> JLS clarifies the intent:
>
>     @C int @A [] @B [] f;
>
>     "@A applies to the array type int[][], @B applies to its component
> type int[],
>     and @C applies to the element type int."
>
> So according to that, our example would have to be:
>
>     @Email String[] emails;
>
> But obviously this conflicts with the existing semantics of applying
> constraints to arrays (not their elements) in BV 1.1.
>
> So based on that, I don't see a good way for supporting container
> element constraints for arrays. Hence my suggestion is to not support
> them in the BV 2.0 spec (the validation of container elements of
> generic containers - List<@Email String> - is not affected). Specific
> implementations may explore ways around it (e.g. specifying the target
> via payload()) and we may revisit it in 2.1.
>
> Any thoughts?
>
> --Gunnar
>
> [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.4
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/5ebc0583/attachment.html 

From emmanuel at hibernate.org  Wed Apr 19 07:46:21 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 19 Apr 2017 13:46:21 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
Message-ID: <20170419114621.GK17322@hibernate.org>

What you are inferring is that the JLS made an incompatible move right?
Because before Java 8, @Size(max=5) String[] was meant to be applied on
the array right?

Anyways, I don't think that would be a massive loss to lose array
support but my background is biased toward preferring collections.

Emmanuel

On Wed 17-04-19 10:27, Gunnar Morling wrote:
>Hi,
>
>Guillaume made an important observation concerning the validation of
>array elements. So far we envisioned to support this:
>
>    String @Email [] emails;
>
>That looks nice (provided that @Email supports TYPE_USE), only that
>it's getting semantics of type annotations for arrays wrong.
>
>As per the JLS [1], the @Email annotation here applies to the array
>type String[], not the component type String. This example from the
>JLS clarifies the intent:
>
>    @C int @A [] @B [] f;
>
>    "@A applies to the array type int[][], @B applies to its component
>type int[],
>    and @C applies to the element type int."
>
>So according to that, our example would have to be:
>
>    @Email String[] emails;
>
>But obviously this conflicts with the existing semantics of applying
>constraints to arrays (not their elements) in BV 1.1.
>
>So based on that, I don't see a good way for supporting container
>element constraints for arrays. Hence my suggestion is to not support
>them in the BV 2.0 spec (the validation of container elements of
>generic containers - List<@Email String> - is not affected). Specific
>implementations may explore ways around it (e.g. specifying the target
>via payload()) and we may revisit it in 2.1.
>
>Any thoughts?
>
>--Gunnar
>
>[1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.4
>_______________________________________________
>beanvalidation-dev mailing list
>beanvalidation-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Wed Apr 19 08:04:01 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 19 Apr 2017 14:04:01 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <20170419114621.GK17322@hibernate.org>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
Message-ID: <CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>

2017-04-19 13:46 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> What you are inferring is that the JLS made an incompatible move right?
> Because before Java 8, @Size(max=5) String[] was meant to be applied on
> the array right?

It's not incompatible. Before, there were no TYPE_USE annotations. But
now, an annotation can be both at the same time:

    "It is possible for @Foo to be both a declaration annotation and a
type annotation simultaneously."

The thing is that we added TYPE_USE as supported element type for all
built-in annotations, so we now cannot tell apart whether that @Email
is meant as field-level constraint (targeting the array) or as type
annotation (targeting the component type). A new constraint annotation
member or defined payload could be used to provide that information,
but I'd prefer implementations to experiment with that first.

>
> Anyways, I don't think that would be a massive loss to lose array
> support but my background is biased toward preferring collections.

Yes, my thinking, too. It should be possible to add later, though. In
that light spending the cycles on array support wasn't for nothing,
e.g. we found names ("container element constraints") which will work
for both usages down the road.

>
> Emmanuel
>
> On Wed 17-04-19 10:27, Gunnar Morling wrote:
>>Hi,
>>
>>Guillaume made an important observation concerning the validation of
>>array elements. So far we envisioned to support this:
>>
>>    String @Email [] emails;
>>
>>That looks nice (provided that @Email supports TYPE_USE), only that
>>it's getting semantics of type annotations for arrays wrong.
>>
>>As per the JLS [1], the @Email annotation here applies to the array
>>type String[], not the component type String. This example from the
>>JLS clarifies the intent:
>>
>>    @C int @A [] @B [] f;
>>
>>    "@A applies to the array type int[][], @B applies to its component
>>type int[],
>>    and @C applies to the element type int."
>>
>>So according to that, our example would have to be:
>>
>>    @Email String[] emails;
>>
>>But obviously this conflicts with the existing semantics of applying
>>constraints to arrays (not their elements) in BV 1.1.
>>
>>So based on that, I don't see a good way for supporting container
>>element constraints for arrays. Hence my suggestion is to not support
>>them in the BV 2.0 spec (the validation of container elements of
>>generic containers - List<@Email String> - is not affected). Specific
>>implementations may explore ways around it (e.g. specifying the target
>>via payload()) and we may revisit it in 2.1.
>>
>>Any thoughts?
>>
>>--Gunnar
>>
>>[1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.4
>>_______________________________________________
>>beanvalidation-dev mailing list
>>beanvalidation-dev at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From hendrik.ebbers at me.com  Wed Apr 19 08:42:27 2017
From: hendrik.ebbers at me.com (Hendrik Ebbers)
Date: Wed, 19 Apr 2017 14:42:27 +0200
Subject: [bv-dev] Conflict issue with value extraction and JavaFX
 collection types
In-Reply-To: <20170418125759.GC17322@hibernate.org>
References: <CALt0+o_C-_upB2+X9n70gTX3AJV59UvVEgFORsjPgbwnLrv1pA@mail.gmail.com>
	<20170418125759.GC17322@hibernate.org>
Message-ID: <9E6028ED-DD75-46E8-8EC7-3D74FE6EF5BD@me.com>

I think this is not a JavaFX specific problem. This can happen everywhere if you have defined extractors for 2 interface types and and have an implementation of both. 
In this specific example I would prefer to define ListProperty as a List.

In general I think that this problem might / will happen in other frameworks and APIs, too.

I added such an example in a mail about the usage of annotations in the generic information:

Until now I only worked with lists and here the approach is quite nice. Sadly it won?t work always. By adding an constraints annotation to the generic type of the list we know that the annotation mentions the content of the list. But this is only working because of one point: The generic type of a collection defines the type of the collection content. This works fine for collections (and for example JavaFX properties) but in other cases this will end in problems.

Let?s say we have the following 2 interfaces:

public interface CachedValue<V> {
    V getCachedValue();
}

public interface RealValue<V> {
    V getRealValue();
}

Based on this interfaces we can easily create a new class that implements both interfaces:

public class CachableValue<V> implements CachedValue<V>, RealValue<V> {

    private V cachedValue;

    @Override
    public V getCachedValue() {
        return cachedValue;
    }

    @Override
    public V getRealValue() {
        V realValue = receiveValueFromServer();
        cachedValue = realValue;
        return realValue;
    }

    private V receiveValueFromServer() {
        return ServerConnector.getCurrentValue(); //Some fake code
    }
}



> Am 18.04.2017 um 14:57 schrieb Emmanuel Bernard <emmanuel at hibernate.org>:
> 
> I'm not using JavaFX but I would be in favor of 2. because it let's
> people put a size constraint on the List.
> 
> Have you considered a blog post to get more feedback. Here people don't
> use JavaFX or are shy.
> 
> On Wed 17-04-12 16:16, Guillaume Smet wrote:
>> Hi,
>> 
>> We are refining the value extraction work and one of the remaining tasks is
>> to throw a proper exception if we have ValueExtractors defined in parallel
>> hierarchies for a given type.
>> 
>> This led to discovering the below issue with the JavaFX collection types.
>> 
>> Let's take the ListProperty example (we have the same issue with Set and
>> Map): ListProperty inherits from ObservableValue and from List.
>> 
>> For now, it uses (by chance) the ObservableValue extractor which unwraps
>> the value by default. So basically:
>> @NotNull
>> private ListProperty<String> listProperty = new
>> ReadOnlyListWrapper<String>( null );
>> will return a violation.
>> 
>> With the new conflict detection, it will throw an exception as it's unable
>> to find ONE most specific ValueExtractor as there are 2 valid candidates:
>> ObservableValueValueExtractor and ListValueExtractor.
>> 
>> If we want to solve the conflict, we need to introduce a specific
>> ValueExtractor for ListProperty and decide of its behavior.
>> 
>> We have 2 possibilities:
>> 1/ consider ListProperty as an ObservableValue and thus simply unwrap the
>> list and validate the constraint against the list. In the above example,
>> @NotNull would then apply to the inner list. Same behavior as explained
>> above.
>> 2/ consider ListProperty as a List. Thus the value extractor would iterate
>> over the element of the list. In the above case, it won't return a
>> violation. In the below example, the @NotNull would refer to listProperty
>> itself and the constraints on the elements of the list would be validated:
>> @NotNull
>> private ListProperty<@Size(min = 3) String> listProperty = new
>> ReadOnlyListWrapper<String>( null );
>> 
>> Gunnar and I are in favor of 2/ but it changes the current behavior as the
>> @NotNull would refer to the container instead of referring to the wrapped
>> value.
>> 
>> We would really like to have some feedback from people using JavaFX.
>> 
>> Thanks!
>> 
>> -- 
>> Guillaume
> 
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/ef51b453/attachment.html 

From misterm at gmail.com  Wed Apr 19 10:35:12 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 19 Apr 2017 11:35:12 -0300
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
Message-ID: <CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>

Hi Gunnar,

In order to preserve compatibility, I think we should require a specific
option to be set in the factory to enable array element validation. This
way, new projects have full support. What do you think?

Regards,
Michael

On Wed, Apr 19, 2017 at 9:04 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2017-04-19 13:46 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > What you are inferring is that the JLS made an incompatible move right?
> > Because before Java 8, @Size(max=5) String[] was meant to be applied on
> > the array right?
>
> It's not incompatible. Before, there were no TYPE_USE annotations. But
> now, an annotation can be both at the same time:
>
>     "It is possible for @Foo to be both a declaration annotation and a
> type annotation simultaneously."
>
> The thing is that we added TYPE_USE as supported element type for all
> built-in annotations, so we now cannot tell apart whether that @Email
> is meant as field-level constraint (targeting the array) or as type
> annotation (targeting the component type). A new constraint annotation
> member or defined payload could be used to provide that information,
> but I'd prefer implementations to experiment with that first.
>
> >
> > Anyways, I don't think that would be a massive loss to lose array
> > support but my background is biased toward preferring collections.
>
> Yes, my thinking, too. It should be possible to add later, though. In
> that light spending the cycles on array support wasn't for nothing,
> e.g. we found names ("container element constraints") which will work
> for both usages down the road.
>
> >
> > Emmanuel
> >
> > On Wed 17-04-19 10:27, Gunnar Morling wrote:
> >>Hi,
> >>
> >>Guillaume made an important observation concerning the validation of
> >>array elements. So far we envisioned to support this:
> >>
> >>    String @Email [] emails;
> >>
> >>That looks nice (provided that @Email supports TYPE_USE), only that
> >>it's getting semantics of type annotations for arrays wrong.
> >>
> >>As per the JLS [1], the @Email annotation here applies to the array
> >>type String[], not the component type String. This example from the
> >>JLS clarifies the intent:
> >>
> >>    @C int @A [] @B [] f;
> >>
> >>    "@A applies to the array type int[][], @B applies to its component
> >>type int[],
> >>    and @C applies to the element type int."
> >>
> >>So according to that, our example would have to be:
> >>
> >>    @Email String[] emails;
> >>
> >>But obviously this conflicts with the existing semantics of applying
> >>constraints to arrays (not their elements) in BV 1.1.
> >>
> >>So based on that, I don't see a good way for supporting container
> >>element constraints for arrays. Hence my suggestion is to not support
> >>them in the BV 2.0 spec (the validation of container elements of
> >>generic containers - List<@Email String> - is not affected). Specific
> >>implementations may explore ways around it (e.g. specifying the target
> >>via payload()) and we may revisit it in 2.1.
> >>
> >>Any thoughts?
> >>
> >>--Gunnar
> >>
> >>[1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-
> 9.html#jls-9.7.4
> >>_______________________________________________
> >>beanvalidation-dev mailing list
> >>beanvalidation-dev at lists.jboss.org
> >>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/4047c84d/attachment.html 

From mbenson at apache.org  Wed Apr 19 10:40:58 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 19 Apr 2017 09:40:58 -0500
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
Message-ID: <CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>

FWIW, I was thinking something along the same lines as Michael.

Matt

On Wed, Apr 19, 2017 at 9:35 AM, Michael Nascimento <misterm at gmail.com>
wrote:

> Hi Gunnar,
>
> In order to preserve compatibility, I think we should require a specific
> option to be set in the factory to enable array element validation. This
> way, new projects have full support. What do you think?
>
> Regards,
> Michael
>
> On Wed, Apr 19, 2017 at 9:04 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 2017-04-19 13:46 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> > What you are inferring is that the JLS made an incompatible move right?
>> > Because before Java 8, @Size(max=5) String[] was meant to be applied on
>> > the array right?
>>
>> It's not incompatible. Before, there were no TYPE_USE annotations. But
>> now, an annotation can be both at the same time:
>>
>>     "It is possible for @Foo to be both a declaration annotation and a
>> type annotation simultaneously."
>>
>> The thing is that we added TYPE_USE as supported element type for all
>> built-in annotations, so we now cannot tell apart whether that @Email
>> is meant as field-level constraint (targeting the array) or as type
>> annotation (targeting the component type). A new constraint annotation
>> member or defined payload could be used to provide that information,
>> but I'd prefer implementations to experiment with that first.
>>
>> >
>> > Anyways, I don't think that would be a massive loss to lose array
>> > support but my background is biased toward preferring collections.
>>
>> Yes, my thinking, too. It should be possible to add later, though. In
>> that light spending the cycles on array support wasn't for nothing,
>> e.g. we found names ("container element constraints") which will work
>> for both usages down the road.
>>
>> >
>> > Emmanuel
>> >
>> > On Wed 17-04-19 10:27, Gunnar Morling wrote:
>> >>Hi,
>> >>
>> >>Guillaume made an important observation concerning the validation of
>> >>array elements. So far we envisioned to support this:
>> >>
>> >>    String @Email [] emails;
>> >>
>> >>That looks nice (provided that @Email supports TYPE_USE), only that
>> >>it's getting semantics of type annotations for arrays wrong.
>> >>
>> >>As per the JLS [1], the @Email annotation here applies to the array
>> >>type String[], not the component type String. This example from the
>> >>JLS clarifies the intent:
>> >>
>> >>    @C int @A [] @B [] f;
>> >>
>> >>    "@A applies to the array type int[][], @B applies to its component
>> >>type int[],
>> >>    and @C applies to the element type int."
>> >>
>> >>So according to that, our example would have to be:
>> >>
>> >>    @Email String[] emails;
>> >>
>> >>But obviously this conflicts with the existing semantics of applying
>> >>constraints to arrays (not their elements) in BV 1.1.
>> >>
>> >>So based on that, I don't see a good way for supporting container
>> >>element constraints for arrays. Hence my suggestion is to not support
>> >>them in the BV 2.0 spec (the validation of container elements of
>> >>generic containers - List<@Email String> - is not affected). Specific
>> >>implementations may explore ways around it (e.g. specifying the target
>> >>via payload()) and we may revisit it in 2.1.
>> >>
>> >>Any thoughts?
>> >>
>> >>--Gunnar
>> >>
>> >>[1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.
>> html#jls-9.7.4
>> >>_______________________________________________
>> >>beanvalidation-dev mailing list
>> >>beanvalidation-dev at lists.jboss.org
>> >>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/6bc7035c/attachment-0001.html 

From gunnar at hibernate.org  Wed Apr 19 11:03:10 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 19 Apr 2017 17:03:10 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
Message-ID: <CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>

What would that option do, though?

When looking at

    @Size(min = 2)
    private String[] array;

Then we cannot tell what's the target of the @Size annotation, String
or String[]. As per Java 8's annotation semantics it can be both
(provided FIELD and TYPE_USE are among the supported element types).

Even if there was an option for deciding it one way or the other, it's
unclear when looking at this code (and not knowing the option's
setting). Which I consider a nasty usability issue. Worse, code
written prior to BV 2 would change its semantics based on the option.
Also what if you wanted one @Size to apply to the array and another
@Size to the contained Strings?

Hence my preference for something more explicit, but I think we should
rather let implementations experiment with that and revisit it in BV
2.1 (whenever we do that). Note that this is doable now as all
built-in annotations support TYPE_USE (which was blocking
provider-specific experiments prior to 2.0).

--Gunnar




2017-04-19 16:40 GMT+02:00 Matt Benson <mbenson at apache.org>:
> FWIW, I was thinking something along the same lines as Michael.
>
> Matt
>
> On Wed, Apr 19, 2017 at 9:35 AM, Michael Nascimento <misterm at gmail.com>
> wrote:
>>
>> Hi Gunnar,
>>
>> In order to preserve compatibility, I think we should require a specific
>> option to be set in the factory to enable array element validation. This
>> way, new projects have full support. What do you think?
>>
>> Regards,
>> Michael
>>
>> On Wed, Apr 19, 2017 at 9:04 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> 2017-04-19 13:46 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> > What you are inferring is that the JLS made an incompatible move right?
>>> > Because before Java 8, @Size(max=5) String[] was meant to be applied on
>>> > the array right?
>>>
>>> It's not incompatible. Before, there were no TYPE_USE annotations. But
>>> now, an annotation can be both at the same time:
>>>
>>>     "It is possible for @Foo to be both a declaration annotation and a
>>> type annotation simultaneously."
>>>
>>> The thing is that we added TYPE_USE as supported element type for all
>>> built-in annotations, so we now cannot tell apart whether that @Email
>>> is meant as field-level constraint (targeting the array) or as type
>>> annotation (targeting the component type). A new constraint annotation
>>> member or defined payload could be used to provide that information,
>>> but I'd prefer implementations to experiment with that first.
>>>
>>> >
>>> > Anyways, I don't think that would be a massive loss to lose array
>>> > support but my background is biased toward preferring collections.
>>>
>>> Yes, my thinking, too. It should be possible to add later, though. In
>>> that light spending the cycles on array support wasn't for nothing,
>>> e.g. we found names ("container element constraints") which will work
>>> for both usages down the road.
>>>
>>> >
>>> > Emmanuel
>>> >
>>> > On Wed 17-04-19 10:27, Gunnar Morling wrote:
>>> >>Hi,
>>> >>
>>> >>Guillaume made an important observation concerning the validation of
>>> >>array elements. So far we envisioned to support this:
>>> >>
>>> >>    String @Email [] emails;
>>> >>
>>> >>That looks nice (provided that @Email supports TYPE_USE), only that
>>> >>it's getting semantics of type annotations for arrays wrong.
>>> >>
>>> >>As per the JLS [1], the @Email annotation here applies to the array
>>> >>type String[], not the component type String. This example from the
>>> >>JLS clarifies the intent:
>>> >>
>>> >>    @C int @A [] @B [] f;
>>> >>
>>> >>    "@A applies to the array type int[][], @B applies to its component
>>> >>type int[],
>>> >>    and @C applies to the element type int."
>>> >>
>>> >>So according to that, our example would have to be:
>>> >>
>>> >>    @Email String[] emails;
>>> >>
>>> >>But obviously this conflicts with the existing semantics of applying
>>> >>constraints to arrays (not their elements) in BV 1.1.
>>> >>
>>> >>So based on that, I don't see a good way for supporting container
>>> >>element constraints for arrays. Hence my suggestion is to not support
>>> >>them in the BV 2.0 spec (the validation of container elements of
>>> >>generic containers - List<@Email String> - is not affected). Specific
>>> >>implementations may explore ways around it (e.g. specifying the target
>>> >>via payload()) and we may revisit it in 2.1.
>>> >>
>>> >>Any thoughts?
>>> >>
>>> >>--Gunnar
>>> >>
>>> >>[1]
>>> >> https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.4
>>> >>_______________________________________________
>>> >>beanvalidation-dev mailing list
>>> >>beanvalidation-dev at lists.jboss.org
>>> >>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> > _______________________________________________
>>> > beanvalidation-dev mailing list
>>> > beanvalidation-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Wed Apr 19 11:09:48 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 19 Apr 2017 12:09:48 -0300
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
	<CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
Message-ID: <CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>

On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Then we cannot tell what's the target of the @Size annotation, String
> or String[]. As per Java 8's annotation semantics it can be both
> (provided FIELD and TYPE_USE are among the supported element types).
>

This point worries me. So you're saying there's a flaw in *the language
design* for this JSR in this particular case, is that right? I said it
before, but since now we got to a point you''re stating (maybe rightfully,
don't take me wrong!) the language is broken in the specific case of
annotations involving arrays, it would be nice to contact the spec leads
for the JSR in order to see (a) if we missed something (then we should
revisit the solution) or (b) to get the language fixed for Java SE 10 (for
9 I think it wouldn't make it even though it's a bug fix) and in this case
provide no support until we release BV for that version of Java.

Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/f4327cb3/attachment.html 

From mbenson at apache.org  Wed Apr 19 11:38:02 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 19 Apr 2017 10:38:02 -0500
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
	<CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
	<CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
Message-ID: <CAE9L6G031DC82gdEGSxk-B5PvsrrjB6evfdW+BS5OD4PAjwkwg@mail.gmail.com>

My understanding was that using:

@Size(2) String[] arrayOfTwoStrings;

was basically "wrong" according to the new annotation semantics. Rather
you'd have:

@Size(2) String[] arrayOfTwoCharacterCodes;
String @Size(2) [] arrayOfTwoStrings;

The "nuclear" option is to adopt this wholeheartedly in BV 2.0. We could
additionally support a "compatibility mode" that, if enabled, would
preserve the BV 1.x constrained array semantics, with no Java-based option
to validate each element  (as the appropriate constraint position has been
hijacked). Alternatively, a given BV implementation could support a special
mode to turn on the "new" behavior, but that would probably be much more
messy for re-unifying the specification and implementations in the future.

Matt

On Wed, Apr 19, 2017 at 10:09 AM, Michael Nascimento <misterm at gmail.com>
wrote:

> On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Then we cannot tell what's the target of the @Size annotation, String
>> or String[]. As per Java 8's annotation semantics it can be both
>> (provided FIELD and TYPE_USE are among the supported element types).
>>
>
> This point worries me. So you're saying there's a flaw in *the language
> design* for this JSR in this particular case, is that right? I said it
> before, but since now we got to a point you''re stating (maybe rightfully,
> don't take me wrong!) the language is broken in the specific case of
> annotations involving arrays, it would be nice to contact the spec leads
> for the JSR in order to see (a) if we missed something (then we should
> revisit the solution) or (b) to get the language fixed for Java SE 10 (for
> 9 I think it wouldn't make it even though it's a bug fix) and in this case
> provide no support until we release BV for that version of Java.
>
> Regards,
> Michael
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/f41ee527/attachment.html 

From gunnar at hibernate.org  Wed Apr 19 14:56:52 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 19 Apr 2017 20:56:52 +0200
Subject: [bv-dev] Moving container element validation from appendix to
	actual spec
Message-ID: <CADGJaX8z9D_QjqYnGbipyFu37smT2oTqmmfb4xkjjaeXF_VxZA@mail.gmail.com>

Hi,

I've just filed a PR [1] for pulling the container element validation
proposal into the actual spec chapter.

Some smaller details are still missing (metadata API extension as per
the pending API PR, more examples), but it should be good for review
overall. Could you let me know of your thoughts by Friday, please? In
terms of actual contents, nothing dramatical has changed compared to
the appendix, I've mostly improved wording, clarified details etc.

In the light of today's discussion this doesn't contain container
element validation for arrays. I'm not super happy about omitting it,
but it feels safer to leave that one for another time (and we could
still add it back during the public review, should we find a
satisfying solution and feel very confident about it).

Once that one is merged, I'll prepare the Public Draft over the
weekend, it should be up for review next week then. I'll post the
original appendix to the proposals page on beanvalidation.org for
future reference.

Looking forward to any feedback,

--Gunnar

[1] https://github.com/beanvalidation/beanvalidation-spec/pull/153

From emmanuel at hibernate.org  Wed Apr 19 15:27:34 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 19 Apr 2017 21:27:34 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CAE9L6G031DC82gdEGSxk-B5PvsrrjB6evfdW+BS5OD4PAjwkwg@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
	<CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
	<CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
	<CAE9L6G031DC82gdEGSxk-B5PvsrrjB6evfdW+BS5OD4PAjwkwg@mail.gmail.com>
Message-ID: <86C53274-5445-4AD0-8F69-08F8190B497C@hibernate.org>

not quite

    @Target(FIELD)
    @interface Size
    
    @Size(2) String[] arrayOfTwoStrings;

is valid in Java 7 and 8


But
    @Target(FIELD, TYPE_USE)
    @interface Size
    
    @Size(2) String[] arrayOfTwoStrings;

is ambiguous in Java 8

So the JLS is ?backward compatible? in the language designer?s view I suppose. They did not anticipate people wanting to add TYPE_USE to an existing annotation and have a side effect on its usage on arrays.

Emmanuel


> On 19 Apr 2017, at 17:38, Matt Benson <mbenson at apache.org> wrote:
> 
> My understanding was that using:
> 
> @Size(2) String[] arrayOfTwoStrings;
> 
> was basically "wrong" according to the new annotation semantics. Rather you'd have:
> 
> @Size(2) String[] arrayOfTwoCharacterCodes;
> String @Size(2) [] arrayOfTwoStrings;
> 
> The "nuclear" option is to adopt this wholeheartedly in BV 2.0. We could additionally support a "compatibility mode" that, if enabled, would preserve the BV 1.x constrained array semantics, with no Java-based option to validate each element  (as the appropriate constraint position has been hijacked). Alternatively, a given BV implementation could support a special mode to turn on the "new" behavior, but that would probably be much more messy for re-unifying the specification and implementations in the future.
> 
> Matt
> 
> On Wed, Apr 19, 2017 at 10:09 AM, Michael Nascimento <misterm at gmail.com <mailto:misterm at gmail.com>> wrote:
> On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling <gunnar at hibernate.org <mailto:gunnar at hibernate.org>> wrote:
> Then we cannot tell what's the target of the @Size annotation, String
> or String[]. As per Java 8's annotation semantics it can be both
> (provided FIELD and TYPE_USE are among the supported element types).
> 
> This point worries me. So you're saying there's a flaw in *the language design* for this JSR in this particular case, is that right? I said it before, but since now we got to a point you''re stating (maybe rightfully, don't take me wrong!) the language is broken in the specific case of annotations involving arrays, it would be nice to contact the spec leads for the JSR in order to see (a) if we missed something (then we should revisit the solution) or (b) to get the language fixed for Java SE 10 (for 9 I think it wouldn't make it even though it's a bug fix) and in this case provide no support until we release BV for that version of Java.
> 
> Regards,
> Michael
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org <mailto:beanvalidation-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev <https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/28e4237d/attachment-0001.html 

From emmanuel at hibernate.org  Wed Apr 19 15:29:26 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 19 Apr 2017 21:29:26 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
	<CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
	<CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
Message-ID: <5A84E5BB-F756-44CD-A04E-CAE475FED2AD@hibernate.org>

BTW +1 to the idea of writing a well written blog explaining our problem and open a JDK issue asking for advice.
My guess is that it won?t go anywhere but that?s worth trying.

> On 19 Apr 2017, at 17:09, Michael Nascimento <misterm at gmail.com> wrote:
> 
> On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling <gunnar at hibernate.org <mailto:gunnar at hibernate.org>> wrote:
> Then we cannot tell what's the target of the @Size annotation, String
> or String[]. As per Java 8's annotation semantics it can be both
> (provided FIELD and TYPE_USE are among the supported element types).
> 
> This point worries me. So you're saying there's a flaw in *the language design* for this JSR in this particular case, is that right? I said it before, but since now we got to a point you''re stating (maybe rightfully, don't take me wrong!) the language is broken in the specific case of annotations involving arrays, it would be nice to contact the spec leads for the JSR in order to see (a) if we missed something (then we should revisit the solution) or (b) to get the language fixed for Java SE 10 (for 9 I think it wouldn't make it even though it's a bug fix) and in this case provide no support until we release BV for that version of Java.
> 
> Regards,
> Michael
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/baed4c38/attachment.html 

From misterm at gmail.com  Wed Apr 19 16:07:49 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 19 Apr 2017 17:07:49 -0300
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <86C53274-5445-4AD0-8F69-08F8190B497C@hibernate.org>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
	<CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
	<CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
	<CAE9L6G031DC82gdEGSxk-B5PvsrrjB6evfdW+BS5OD4PAjwkwg@mail.gmail.com>
	<86C53274-5445-4AD0-8F69-08F8190B497C@hibernate.org>
Message-ID: <CAAWA2oW3Tv4DG2LM2r_+0P5K2L0edz5zC6bp4BTr6A3O8VY86A@mail.gmail.com>

On Wed, Apr 19, 2017 at 4:27 PM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> But
>     @Target(FIELD, TYPE_USE)
>     @interface Size
>
>     @Size(2) String[] arrayOfTwoStrings;
>
> is ambiguous in Java 8
>
> So the JLS is ?backward compatible? in the language designer?s view I
> suppose.
>

When you don't change, it's backward compatible indeed. When you do, the
language design is flawed. So there is a hole in one combination that needs
to be addressed. Joshua Bloch would write about that all the time, of how
new features interact in unexpected ways and that's why you have to resist
changes in the language.


> They did not anticipate people wanting to add TYPE_USE to an existing
> annotation and have a side effect on its usage on arrays.
>

Exactly, so this is effectively broken and needs to be fixed in the
language, not in BV. But I'm still afraid we might have got something wrong
here, so I would rather ask them.

Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/1178c820/attachment.html 

From moltenma at gmail.com  Thu Apr 20 02:20:41 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Thu, 20 Apr 2017 08:20:41 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CAAWA2oW3Tv4DG2LM2r_+0P5K2L0edz5zC6bp4BTr6A3O8VY86A@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
	<CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
	<CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
	<CAE9L6G031DC82gdEGSxk-B5PvsrrjB6evfdW+BS5OD4PAjwkwg@mail.gmail.com>
	<86C53274-5445-4AD0-8F69-08F8190B497C@hibernate.org>
	<CAAWA2oW3Tv4DG2LM2r_+0P5K2L0edz5zC6bp4BTr6A3O8VY86A@mail.gmail.com>
Message-ID: <CANUPYM32dmecerif4Do_Y8mXprHSH_ZT6vNAZdG3QyQsZOvHzA@mail.gmail.com>

@Gunnar
I agree that is better to omit (until clarification) the array problem from
the spec.
Could you give a try contacting the spec lead for the JDK, as suggested by
Michael and Emmanuel, to see if a (future) clean solution is possible?

>From a more realistic perspective (seeing the schedule and what happens in
other JSR) I think that the solution you and Guillaume suggested (backward
compatibility and wait for the 2.1) doesn't have many alternatives.

Thanks


On Wed, Apr 19, 2017 at 10:07 PM, Michael Nascimento <misterm at gmail.com>
wrote:

> On Wed, Apr 19, 2017 at 4:27 PM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>> But
>>     @Target(FIELD, TYPE_USE)
>>     @interface Size
>>
>>     @Size(2) String[] arrayOfTwoStrings;
>>
>> is ambiguous in Java 8
>>
>> So the JLS is ?backward compatible? in the language designer?s view I
>> suppose.
>>
>
> When you don't change, it's backward compatible indeed. When you do, the
> language design is flawed. So there is a hole in one combination that needs
> to be addressed. Joshua Bloch would write about that all the time, of how
> new features interact in unexpected ways and that's why you have to resist
> changes in the language.
>
>
>> They did not anticipate people wanting to add TYPE_USE to an existing
>> annotation and have a side effect on its usage on arrays.
>>
>
> Exactly, so this is effectively broken and needs to be fixed in the
> language, not in BV. But I'm still afraid we might have got something wrong
> here, so I would rather ask them.
>
> Regards,
> Michael
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170420/a4416cb9/attachment.html 

From gunnar at hibernate.org  Thu Apr 20 04:17:30 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 20 Apr 2017 10:17:30 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CAAWA2oW3Tv4DG2LM2r_+0P5K2L0edz5zC6bp4BTr6A3O8VY86A@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
	<CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
	<CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
	<CAE9L6G031DC82gdEGSxk-B5PvsrrjB6evfdW+BS5OD4PAjwkwg@mail.gmail.com>
	<86C53274-5445-4AD0-8F69-08F8190B497C@hibernate.org>
	<CAAWA2oW3Tv4DG2LM2r_+0P5K2L0edz5zC6bp4BTr6A3O8VY86A@mail.gmail.com>
Message-ID: <CADGJaX_KkTKUfL9eANtHP66dLOwk6izax6tMLVQMbzTDw5h4+g@mail.gmail.com>

2017-04-19 22:07 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> On Wed, Apr 19, 2017 at 4:27 PM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>>
>> But
>>     @Target(FIELD, TYPE_USE)
>>     @interface Size
>>
>>     @Size(2) String[] arrayOfTwoStrings;
>>
>> is ambiguous in Java 8
>>
>> So the JLS is ?backward compatible? in the language designer?s view I
>> suppose.
>
>
> When you don't change, it's backward compatible indeed. When you do, the
> language design is flawed. So there is a hole in one combination that needs
> to be addressed. Joshua Bloch would write about that all the time, of how
> new features interact in unexpected ways and that's why you have to resist
> changes in the language.
>
>>
>> They did not anticipate people wanting to add TYPE_USE to an existing
>> annotation and have a side effect on its usage on arrays.
>
>
> Exactly, so this is effectively broken and needs to be fixed in the
> language, not in BV. But I'm still afraid we might have got something wrong
> here, so I would rather ask them.

I've sent a mail to the compiler-dev mailing list (best place I could think of):

    http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010918.html

Let's see what answers we get. I don't think it will be fixed in the
language (how?), esp. given that the JLS is clearly aware of that
ambiguity.

>
> Regards,
> Michael
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From gunnar at hibernate.org  Thu Apr 20 04:19:45 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 20 Apr 2017 10:19:45 +0200
Subject: [bv-dev] Container element validation for arrays
In-Reply-To: <CAE9L6G031DC82gdEGSxk-B5PvsrrjB6evfdW+BS5OD4PAjwkwg@mail.gmail.com>
References: <CADGJaX8nVRxCSBxqY7i7w3ziOw1orK=EDOsfnDPG==vnqLnRpQ@mail.gmail.com>
	<20170419114621.GK17322@hibernate.org>
	<CADGJaX9K4E=eZM0qU7VX--piWgWHZPcHRENA9by3GR_NF1h6Xw@mail.gmail.com>
	<CAAWA2oVk0GJUQfaGdRrtNP2pjNR4ZcLo90VfP7Pz3X75X-S5MQ@mail.gmail.com>
	<CAE9L6G0stZf+Bd1xe5kbMG16Dy7HRrTkHwNrVAEES7B52uoAPw@mail.gmail.com>
	<CADGJaX9R+NL9obVUsj-XnH96vr6_StXA+KOhNh8UXnO52+L7fg@mail.gmail.com>
	<CAAWA2oX2bprTumAAEq5Tsad0EoSr79Hc-uHde64z3nEyX0ZfVw@mail.gmail.com>
	<CAE9L6G031DC82gdEGSxk-B5PvsrrjB6evfdW+BS5OD4PAjwkwg@mail.gmail.com>
Message-ID: <CADGJaX87ivn=QvxDW8zmUan9ZaCyKTLUgxoyhAqmWJFrpPKKGQ@mail.gmail.com>

2017-04-19 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
> My understanding was that using:
>
> @Size(2) String[] arrayOfTwoStrings;
>
> was basically "wrong" according to the new annotation semantics. Rather
> you'd have:
>
> @Size(2) String[] arrayOfTwoCharacterCodes;
> String @Size(2) [] arrayOfTwoStrings;
>
> The "nuclear" option is to adopt this wholeheartedly in BV 2.0. We could
> additionally support a "compatibility mode" that, if enabled, would preserve
> the BV 1.x constrained array semantics, with no Java-based option to
> validate each element  (as the appropriate constraint position has been
> hijacked).

Yes, that would be an option. But the "compatibility mode" would have
to be enabled by default I think. We can experiment with that in the
RI.

> Alternatively, a given BV implementation could support a special
> mode to turn on the "new" behavior, but that would probably be much more
> messy for re-unifying the specification and implementations in the future.
>
> Matt
>
> On Wed, Apr 19, 2017 at 10:09 AM, Michael Nascimento <misterm at gmail.com>
> wrote:
>>
>> On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> Then we cannot tell what's the target of the @Size annotation, String
>>> or String[]. As per Java 8's annotation semantics it can be both
>>> (provided FIELD and TYPE_USE are among the supported element types).
>>
>>
>> This point worries me. So you're saying there's a flaw in *the language
>> design* for this JSR in this particular case, is that right? I said it
>> before, but since now we got to a point you''re stating (maybe rightfully,
>> don't take me wrong!) the language is broken in the specific case of
>> annotations involving arrays, it would be nice to contact the spec leads for
>> the JSR in order to see (a) if we missed something (then we should revisit
>> the solution) or (b) to get the language fixed for Java SE 10 (for 9 I think
>> it wouldn't make it even though it's a bug fix) and in this case provide no
>> support until we release BV for that version of Java.
>>
>> Regards,
>> Michael
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Fri Apr 21 02:31:15 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 21 Apr 2017 08:31:15 +0200
Subject: [bv-dev] Conflict issue with value extraction and JavaFX
 collection types
In-Reply-To: <9E6028ED-DD75-46E8-8EC7-3D74FE6EF5BD@me.com>
References: <CALt0+o_C-_upB2+X9n70gTX3AJV59UvVEgFORsjPgbwnLrv1pA@mail.gmail.com>
	<20170418125759.GC17322@hibernate.org>
	<9E6028ED-DD75-46E8-8EC7-3D74FE6EF5BD@me.com>
Message-ID: <CADGJaX9YeJkQ1jDD0oQ0KrP0yqpeB0y=DD+UWqj_0qX_4TQ4OA@mail.gmail.com>

Right, it's an issue with parallel class hierarchies in general. The
same could happen during constraint validator resolution. In both
cases an extractor (or validator) for the specific sub-type must be
provided to resolve the ambiguity. This would also address your case
of cached and real value.

Based on the preference of option 2), I've added this to the pending
PR in the section on built-in extractors:

===
Compatible implementations provide value extractors for the following
types out of the box:

[...]

* javafx.beans.observable.ObservableValue; value() must be invoked
with the observable value, passing null as node name; the extractor
must be marked with @UnwrapByDefault

* javafx.beans.property.ReadOnlyListProperty and
javafx.beans.property.ListProperty; indexedValue() must be invoked for
each contained element, passing the string literal <iterable element>
as node name

* javafx.beans.property.ReadOnlyMapProperty and
javafx.beans.property.MapProperty; both map keys and map values are to
be supported; keyedValue() must be invoked by the map key extractor
for each contained key, passing the string literal <map key> as node
name; keyedValue() must be invoked by the map value extractor for each
contained value, passing the string literal <map value> as node name
===

2017-04-19 14:42 GMT+02:00 Hendrik Ebbers <hendrik.ebbers at me.com>:
> I think this is not a JavaFX specific problem. This can happen everywhere if
> you have defined extractors for 2 interface types and and have an
> implementation of both.
> In this specific example I would prefer to define ListProperty as a List.
>
> In general I think that this problem might / will happen in other frameworks
> and APIs, too.
>
> I added such an example in a mail about the usage of annotations in the
> generic information:
>
> Until now I only worked with lists and here the approach is quite nice.
> Sadly it won?t work always. By adding an constraints annotation to the
> generic type of the list we know that the annotation mentions the content of
> the list. But this is only working because of one point: The generic type of
> a collection defines the type of the collection content. This works fine for
> collections (and for example JavaFX properties) but in other cases this will
> end in problems.
>
> Let?s say we have the following 2 interfaces:
>
> public interface CachedValue<V> {
>     V getCachedValue();
> }
>
> public interface RealValue<V> {
>     V getRealValue();
> }
>
> Based on this interfaces we can easily create a new class that implements
> both interfaces:
>
> public class CachableValue<V> implements CachedValue<V>, RealValue<V> {
>
>     private V cachedValue;
>
>     @Override
>     public V getCachedValue() {
>         return cachedValue;
>     }
>
>     @Override
>     public V getRealValue() {
>         V realValue = receiveValueFromServer();
>         cachedValue = realValue;
>         return realValue;
>     }
>
>     private V receiveValueFromServer() {
>         return ServerConnector.getCurrentValue(); //Some fake code
>     }
> }
>
>
>
>
> Am 18.04.2017 um 14:57 schrieb Emmanuel Bernard <emmanuel at hibernate.org>:
>
> I'm not using JavaFX but I would be in favor of 2. because it let's
> people put a size constraint on the List.
>
> Have you considered a blog post to get more feedback. Here people don't
> use JavaFX or are shy.
>
> On Wed 17-04-12 16:16, Guillaume Smet wrote:
>
> Hi,
>
> We are refining the value extraction work and one of the remaining tasks is
> to throw a proper exception if we have ValueExtractors defined in parallel
> hierarchies for a given type.
>
> This led to discovering the below issue with the JavaFX collection types.
>
> Let's take the ListProperty example (we have the same issue with Set and
> Map): ListProperty inherits from ObservableValue and from List.
>
> For now, it uses (by chance) the ObservableValue extractor which unwraps
> the value by default. So basically:
> @NotNull
> private ListProperty<String> listProperty = new
> ReadOnlyListWrapper<String>( null );
> will return a violation.
>
> With the new conflict detection, it will throw an exception as it's unable
> to find ONE most specific ValueExtractor as there are 2 valid candidates:
> ObservableValueValueExtractor and ListValueExtractor.
>
> If we want to solve the conflict, we need to introduce a specific
> ValueExtractor for ListProperty and decide of its behavior.
>
> We have 2 possibilities:
> 1/ consider ListProperty as an ObservableValue and thus simply unwrap the
> list and validate the constraint against the list. In the above example,
> @NotNull would then apply to the inner list. Same behavior as explained
> above.
> 2/ consider ListProperty as a List. Thus the value extractor would iterate
> over the element of the list. In the above case, it won't return a
> violation. In the below example, the @NotNull would refer to listProperty
> itself and the constraints on the elements of the list would be validated:
> @NotNull
> private ListProperty<@Size(min = 3) String> listProperty = new
> ReadOnlyListWrapper<String>( null );
>
> Gunnar and I are in favor of 2/ but it changes the current behavior as the
> @NotNull would refer to the container instead of referring to the wrapped
> value.
>
> We would really like to have some feedback from people using JavaFX.
>
> Thanks!
>
> --
> Guillaume
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From gunnar at hibernate.org  Fri Apr 21 04:38:56 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 21 Apr 2017 10:38:56 +0200
Subject: [bv-dev] Bean Validation 2.0 Early Draft: Web Container
 Clarification Request
In-Reply-To: <CADGJaX9ThG+Or+LMZ+e71mYfefW4gSJXd-9ARNoxKpar69JU8g@mail.gmail.com>
References: <CAFuRxH3AyO_q3zUGp-mRJ5EcLVP73YkHpq5dyXqze=KzPzeOGw@mail.gmail.com>
	<531CBB4B-F540-4775-A73F-7084A3D33F94@gmail.com>
	<CADGJaX-snCkwbUJd04uaMogNxJbUOtSWLgZ6ZoJw5K1qqiq5Vg@mail.gmail.com>
	<BD68FDD0-374F-4313-A0CB-BDD2BCC0F478@hibernate.org>
	<CADGJaX9o0n7aC=60hgiyj52Z3MfqmJbhHLYF+raJG-CjR4ofeA@mail.gmail.com>
	<F23A2E01-3399-4852-B89B-F48392A1C0F7@hibernate.org>
	<CADGJaX9ThG+Or+LMZ+e71mYfefW4gSJXd-9ARNoxKpar69JU8g@mail.gmail.com>
Message-ID: <CADGJaX_jNuJcUzvUiNM+KQzbNteyqUFT61COKfF38ua01vwgRg@mail.gmail.com>

All,

After discussing this with Linda DeMichiel, this is being resolved within
the Java EE spec which won't mention any specific locations for the
descriptor any longer, instead it refers to the BV spec.

Servers which happened to support WEB-INF/validation.xml should abandon
this in favour of the standard location META-INF/validation.xml, but they
could keep supporting the old one as a fallback (ideally raising a warning
if it's used) to ease migration of existing applications.

I've resolved https://hibernate.atlassian.net/browse/BVAL-581 accordingly.

Thanks again to Nathan for bringing this up.

--Gunnar


2017-03-23 17:36 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> My question then is whether WEB-INF/persistence.xml is supported by JPA or
> not.
>
> From looking at the JPA 2.1 and Java EE 7 specs, that seems not to be the
> case. Also just tried it on WildFly 10.1, and it's ignored when given at
> WEB-INF/persistence.xml.
>
> 2017-03-21 14:40 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
>> As BVAL-200 says, it was intended to support validation.xml int he same
>> places persistence.xml is supported for consistency.
>> Check out what is said about JPA. It might be the same issue though.
>>
>> On 21 Mar 2017, at 01:51, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> BVAL-200 is not exactly the same (I've filed
>> https://hibernate.atlassian.net/browse/BVAL-581 for the current one).
>>
>> BVAL-200 is about the fact that "META-INF" is located within
>> WEB-INF/classes for WARs. All is good with that.
>>
>> But the JavaEE spec actually says that "WEB-INF/validation.xml" (i.e. not
>> "WEB-INF/classes/META-INF/validation.xml") should be used for web
>> modules. AFAICS, this never has worked with the RI, but it seems to be the
>> case for Apache Bval.
>>
>> Emmanuel, do you remember whether it was actually intended to use
>> "WEB-INF/validation.xml" for web modules?
>>
>>
>> 2017-03-21 1:28 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>
>>> https://hibernate.atlassian.net/browse/BVAL-200
>>>
>>> On 20 Mar 2017, at 04:34, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>
>>> Hi,
>>>
>>> Thanks for bringing up this issue, Nathan.
>>>
>>> The Bean Validation spec expects the file to be at
>>> META-INF/validation.xml, no matter what type of application it is. I'll
>>> need to dig a bit deeper why the platform spec mentions
>>> WEB-INF/validation.xml.
>>>
>>> > the TCK uses the WEB-INF/validation.xml location
>>>
>>> Do you have a pointer to this usage? Please send it to me off-list if
>>> it's somewhere within the EE TCK. The BV TCK itself uses
>>> META-INF/validation.xml.
>>>
>>> > Therefore, I'd expect a lot of users in the field to be using the
>>> WEB-INF location
>>>
>>> I just tried WEB-INF/validation.xml in a plain WAR as well as a WAR
>>> within an EAR, and it wouldn't be applied either way (testing the BV
>>> reference implementation). Do you have a test case which shows successful
>>> usage of WEB-INF/validation.xml?
>>>
>>> > Otherwise, the JavaEE Platform spec could be changed to no longer
>>> state WEB-INF/validation.xml
>>>
>>> My current inclination is to suggest exactly that to the Java EE leads,
>>> as it seems like a glitch and I can't see how it'd ever work with the RI. But
>>> I'll synch with Emmanuel (former BV lead) to make sure I'm not missing a
>>> piece.
>>>
>>> @Marco,
>>>
>>> > The implementation of 'WEB-INF/validation.xml' for the web components
>>> and its
>>> > integration with Bean Validation is the full responsibility
>>> (EE.5.16.2) of the Java EE
>>> > Product Provider that declares it
>>>
>>> You seem to suggest that a container somehow may make it that
>>> WEB-INF/validation.xml is exposed as META-INF/validation.xml to the BV
>>> provider. That may theoretically be doable, but I don't think it's intended
>>> or suggested by the EE spec.
>>>
>>> Specifically, section EE.5.16 deals with the "application client
>>> container" property which the container must set depending on where this
>>> app is running (ACC vs. web/EJB container). It's not related to the
>>> retrieval of BV deployment descriptors.
>>>
>>> --Gunnar
>>>
>>>
>>> 2017-03-17 20:03 GMT+01:00 Marco Molteni <moltenma at gmail.com>:
>>>
>>>> Hi Nathan,
>>>>
>>>> I agree that can be confusing for the developers that read the two
>>>> documents but the specification of BV is, IMHO, consistent:
>>>>
>>>> 1.2. Specification Goals:  'The validation API developed by this JSR is
>>>> not intended for use in any one tier or programming model. It is
>>>> specifically not tied to either the web tier or the persistence tier'.
>>>>
>>>> And the JavaEE spec version 7 (and 8) :
>>>> 'EE.5.16.2 Java EE Product Provider?s Responsibilities
>>>> The Java EE Product Provider is responsible for providing the correct
>>>> application client container property as required by this specification.'
>>>>
>>>>
>>>> 'EE.5.17.1 Application Component Provider?s Responsibilities
>>>> [...] The Application Component Provider may customize the
>>>> ValidatorFactory and (indirectly) Validator instances by including a Bean
>>>> Validation deployment descriptor inside a specific module of the
>>>> application.'
>>>>
>>>> 'EE.5.17.2 Java EE Product Provider?s Responsibilities
>>>> [...] These objects must be used to configure the default
>>>> ValidatorFactory available at java:comp/ValidatorFactory in accordance with
>>>> the bootstrapping APIs described by the Bean Validation specification.
>>>> [...]'
>>>>
>>>>
>>>> The implementation of 'WEB-INF/validation.xml' for the web components
>>>> and its integration with Bean Validation is the full responsibility
>>>> (EE.5.16.2) of the Java EE Product Provider that declares it .
>>>> The Bean Validation doesn't have to worry (or know) about the existence
>>>> of a web component or a web configuration directory, it's out of its scope.
>>>> The correct configuration and communication between these (Web and BC)
>>>> and other components is regulated by the container (EE.2.4).
>>>>
>>>> The documents are (maybe) confusing but correct, in my opinion.
>>>>
>>>> Regards
>>>>
>>>> Marco
>>>>
>>>>
>>>> Am 15.03.2017 um 17:39 schrieb Nathan Mittlestat <nmittles at gmail.com>:
>>>>
>>>> Hi All,
>>>>
>>>> One area I'd like to see a clarification on in the spec is around the
>>>> location of the validation.xml in a JavaEE web container environment.  The
>>>> Bean Validation spec indicates the validation.xml is always at
>>>> META-INF/validation.xml.  The JavaEE Platform spec states
>>>> WEB-INF/validation.xml should be used for web modules. The entire Bean
>>>> Validation spec has no mention of web modules, and seems to mainly focus on
>>>> JavaSE.  However, it does mention integration points such as CDI and
>>>> JAX-RS, so I don't think it would be out of line to clarify in the Bean
>>>> Validation spec for web modules.  Otherwise, the JavaEE Platform spec could
>>>> be changed to no longer state WEB-INF/validation.xml, but previous JavaEE
>>>> versions already include this, and the TCK uses the WEB-INF/validation.xml
>>>> location. Therefore, I'd expect a lot of users in the field to be using the
>>>> WEB-INF location.
>>>>
>>>> The Bean Validation spec has the following section (page 206):
>>>> Unless explicitly ignored by calling Configuration.ignoreXMLConfiguration(),
>>>> a Configuration takes into
>>>> account the configuration available in META-INF/validation.xml. This
>>>> configuration file is optional but
>>>> can be used by applications to refine some of the Bean Validation
>>>> behavior. If more than one META-
>>>> INF/validation.xml file is found in the classpath, a
>>>> ValidationException is raised.
>>>>
>>>> In contrasts the JavaEE Platform spec has (page 127 of JavaEE 7):
>>>> In order to customize the returned ValidatorFactory, an EJB, web or
>>>> application client module may specify a Bean Validation XML deployment
>>>> descriptor. The name of the descriptor is WEB-INF/validation.xml for web
>>>> modules and META-INF/validation.xml for all other types of modules.
>>>>
>>>>
>>>>
>>>> --Nathan
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170421/f95331b2/attachment-0001.html 

From gunnar at hibernate.org  Fri Apr 21 05:03:58 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 21 Apr 2017 11:03:58 +0200
Subject: [bv-dev] Moving container element validation from appendix to
	actual spec
In-Reply-To: <CADGJaX8z9D_QjqYnGbipyFu37smT2oTqmmfb4xkjjaeXF_VxZA@mail.gmail.com>
References: <CADGJaX8z9D_QjqYnGbipyFu37smT2oTqmmfb4xkjjaeXF_VxZA@mail.gmail.com>
Message-ID: <CADGJaX895bqPDAdsHeg4RE7DDTYOiYuOSs3+LAXxbqpKSEE6jw@mail.gmail.com>

Hi all,

Any further comments on the container element PR? I'd like to merge it
later today. Of course we can incorporate any feedback also
afterwards, but the earlier, the better.

Thanks,

--Gunnar


2017-04-19 20:56 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> Hi,
>
> I've just filed a PR [1] for pulling the container element validation
> proposal into the actual spec chapter.
>
> Some smaller details are still missing (metadata API extension as per
> the pending API PR, more examples), but it should be good for review
> overall. Could you let me know of your thoughts by Friday, please? In
> terms of actual contents, nothing dramatical has changed compared to
> the appendix, I've mostly improved wording, clarified details etc.
>
> In the light of today's discussion this doesn't contain container
> element validation for arrays. I'm not super happy about omitting it,
> but it feels safer to leave that one for another time (and we could
> still add it back during the public review, should we find a
> satisfying solution and feel very confident about it).
>
> Once that one is merged, I'll prepare the Public Draft over the
> weekend, it should be up for review next week then. I'll post the
> original appendix to the proposals page on beanvalidation.org for
> future reference.
>
> Looking forward to any feedback,
>
> --Gunnar
>
> [1] https://github.com/beanvalidation/beanvalidation-spec/pull/153

From gunnar at hibernate.org  Fri Apr 21 08:55:46 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 21 Apr 2017 14:55:46 +0200
Subject: [bv-dev] Value extraction - how to obtain the validated type
 for non-generic wrappers?
In-Reply-To: <D2B5BB46-5108-4A48-A4F1-9942C06A2C88@hibernate.org>
References: <CADGJaX_2b_xhBPyVLwioJ8BRuKqQOCSBRe0hXJb-6kmCSbhw1Q@mail.gmail.com>
	<D2B5BB46-5108-4A48-A4F1-9942C06A2C88@hibernate.org>
Message-ID: <CADGJaX_F_+dJHJ+-WTAuRNYTY0UWiQECpBQetKiy131V6xEBLw@mail.gmail.com>

2017-03-23 16:39 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> It?s interesting.
> How does that work when Ceylon decides to go for a native support instead of the extraction model? Can they keep a mix?
> I.e. do we prioritize the actual ConstraintViolation<Min,ceylon.language.Integer> over a ValueExtractor<@ExtractedValue ceylon.language.Integer> + ConstraintViolation<Min,Integer>
> I see that you used @UnwrapByDefault, my concern comes from that.

Right, the extractor would be preferred. So Ceylon would have to
provide either the extractor or the dedicated constraint validator.

A related case is Java's OptionalInt, OptionalLong and OptionalDouble.
It'd be nice if all existing constraints for int/long/double would
automatically be applied to them.

Given the point in time I think though I'd rather mandate that the
built-in numeric constraints are supported for those, too, and first
explore the handling of non-generic containers in the RI. In a future
revision this requirement towards BV implementations could be changed
into mandatory value extractors for these types, without breaking user
code.

WDYT?

>
> BTW it will mandate nested extractor support.
>
>> On 23 Mar 2017, at 03:52, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> I've received some very interesting feedback on the value extraction
>> proposal from our team working on the Ceylon language.
>>
>> Ceylon does not only have its own collection framework, but also
>> custom numeric wrappers, e.g. ceylon.language.Integer. Of course it'd
>> be desirable to be able to apply existing constraints such as @Min to
>> these. Instead of creating custom implementations such as
>> ConstraintValidator<Min, ceylon.language.Integer> we thought value
>> extractors could be used to enable all the existing constraints and
>> validators:
>>
>>    @UnwrapByDefault
>>    public class IntegerValueExtractor implements
>>                 ValueExtractor<@ExtractedValue ceylon.language.Integer> {
>>
>>        public void extractValues(
>>            ceylon.language.Integer originalValue, ValueReceiver receiver) {
>>
>>            receiver.value( null, originalValue.getValue() );
>>       }
>>    }
>>
>> The problem only is that BV cannot derive the wrapped type
>> (java.lang.Integer) from the annotated extracted value type
>> (ceylon.language.Integer) in this case, as it isn't generic.
>>
>> My question is: should we support this use case? If so, how? One
>> option I can see is allowing to specify the wrapped type explicitly if
>> the wrapper is non-generic:
>>
>>    public class IntegerValueExtractor implements
>>        ValueExtractor<@ExtractedValue(type=int.class)
>> ceylon.language.Integer> {
>>        ...
>>    }
>>
>> type() would have a default value of void.class, so it doesn't have to
>> be specified if the wrapped type can be derived.
>>
>> We also could decide to not support, requiring integrators such as
>> Ceylon to declare their own constraint validators for BV built-in
>> constraints, but obviously that'd fall short when it comes to
>> 3rd-party custom constraints for basic Java datatypes.
>>
>> Thoughts?
>>
>> --Gunnar
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From gunnar at hibernate.org  Fri Apr 21 09:22:01 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 21 Apr 2017 15:22:01 +0200
Subject: [bv-dev] Jigsaw module name
Message-ID: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>

Hi,

Java 9 is still in the works, so it's too early to put anything final
into the BV spec, but should we add a recommended module name for API
modules?

My thinking is to have a short appendix stating:

    "Implementors that wish to provide the Bean Validation API in form
of a Java 9 module,
     should use the module name "javax.validation". A mandatory module
name will be
     defined in a future revision of this specification".

A commonly agreed on module name is required by Jigsaw to ensure
different API modules (e.g. the reference one and the one provided by
Apache) are interchangeable.

I expect further changes to the spec to support Java 9 down the road
(e.g. to resolve message bundles in client modules and to provide a
way for passing in a Lookup granting private access (see [1]), but
it's nothing we can bake into the spec yet.

Thoughts?

--Gunnar

[1] http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/

From gunnar at hibernate.org  Sun Apr 23 04:51:54 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 23 Apr 2017 10:51:54 +0200
Subject: [bv-dev] Metadata API - Representation of container element
	constraints
Message-ID: <CADGJaX_cQhXafmyUop2bRhpXEG_fLG-4TsqmnsRMPa=2hcpypA@mail.gmail.com>

Hi,

In the constraint metadata API we currently have two new methods:

* getConstraintsForContainerElementType(int) (for returning a
descriptor for a specific type argument) and
* getConstrainedContainerElementTypes() which returns a descriptor for
those type arguments which are constrained or marked for cascaded
validation (themselves or nested).

This is similar to BeanDescriptor#getConstraintsForProperty() and
getConstrainedProperties().

Should we instead have a single method getContainerElementTypes ()
which returns descriptors for all the type arguments of an element, be
them constrained or not? That'd be similar to
ExecutableDescriptor#getParameterDescriptors() where we also return a
descriptor for each parameter. It'd also allow for better evolution
towards array support. That single method would make sense for array
types, too, whereas getConstraintsForContainerElementType(int) is
dubious.

Thus I feel the latter would be a bit better. Thoughts?

Thanks,

--Gunnar

From guillaume.smet at gmail.com  Mon Apr 24 02:57:47 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 24 Apr 2017 08:57:47 +0200
Subject: [bv-dev] Metadata API - Representation of container element
	constraints
In-Reply-To: <CADGJaX_cQhXafmyUop2bRhpXEG_fLG-4TsqmnsRMPa=2hcpypA@mail.gmail.com>
References: <CADGJaX_cQhXafmyUop2bRhpXEG_fLG-4TsqmnsRMPa=2hcpypA@mail.gmail.com>
Message-ID: <CALt0+o-9Ys4o3XJGWHYiQsHWgUmkCwfOoEgT6GtDuenEmcVsyw@mail.gmail.com>

On Sun, Apr 23, 2017 at 10:51 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Thus I feel the latter would be a bit better. Thoughts?
>

I gave it some thoughts this week-end and I think you're right. It makes
more sense to have getContainerElementTypes().

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170424/1b029da9/attachment.html 

From gunnar at hibernate.org  Mon Apr 24 03:50:10 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Apr 2017 09:50:10 +0200
Subject: [bv-dev] Metadata API - Representation of container element
	constraints
In-Reply-To: <CALt0+o-9Ys4o3XJGWHYiQsHWgUmkCwfOoEgT6GtDuenEmcVsyw@mail.gmail.com>
References: <CADGJaX_cQhXafmyUop2bRhpXEG_fLG-4TsqmnsRMPa=2hcpypA@mail.gmail.com>
	<CALt0+o-9Ys4o3XJGWHYiQsHWgUmkCwfOoEgT6GtDuenEmcVsyw@mail.gmail.com>
Message-ID: <CADGJaX8VwY6ZWhOCc0GQ5i=ba9ge3SNi2J9xejK8eAuF6H-GAw@mail.gmail.com>

Ok, let's go for it.

--Gunnar


2017-04-24 8:57 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:
> On Sun, Apr 23, 2017 at 10:51 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> Thus I feel the latter would be a bit better. Thoughts?
>
>
> I gave it some thoughts this week-end and I think you're right. It makes
> more sense to have getContainerElementTypes().
>
> --
> Guillaume
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Mon Apr 24 11:49:04 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Apr 2017 17:49:04 +0200
Subject: [bv-dev] Submitted Public Review Draft
Message-ID: <CADGJaX8oFwS3tnGwueuP932yARHVX=cJgUmr6hKimniffeYeSg@mail.gmail.com>

Hi all,

I've just submitted the draft of the spec for the Public Review to the
JCP; it should be published on jcp.org later this week.

You can find it at the staging environment of our website, too (that's
the diff to 1.1):

    http://staging.beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-1.1/

Once it's published through jcp.org, I'll put out a short blog post to
announce it. Please wait with tweeting etc. until then :) Assuming
it's published on jcp.org on Wednesday, the Public Review will run
until May 26th, followed by two weeks for the ballot (voting by the
EC).

We are going to work on some smaller details around container element
validation next. If there's anything else which you think should be in
there or should be changed, please speak up soon :)

Cheers,

--Gunnar

From mbenson at apache.org  Tue Apr 25 14:05:19 2017
From: mbenson at apache.org (Matt Benson)
Date: Tue, 25 Apr 2017 13:05:19 -0500
Subject: [bv-dev] Questions from BV spec 2.0 public draft
Message-ID: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>

After reviewing the proposed API, I have the following
questions/suggestions. I apologize if any of these have already been
considered:

* Should there be a common superinterface for
Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
the same methods?

* Should ValidatorContext include a self type, as does Configuration?
This would facilitate the use of custom ValidatorContext subclasses.

* Should Positive/Negative#strict() default true be provided as
#orZero() default false, for commonality with
[Past|Future]#orPresent() ?

Matt

From gunnar at hibernate.org  Wed Apr 26 04:40:16 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 26 Apr 2017 10:40:16 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
Message-ID: <CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>

Hi,

2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
> After reviewing the proposed API, I have the following
> questions/suggestions. I apologize if any of these have already been
> considered:
>
> * Should there be a common superinterface for
> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
> the same methods?

I've been wondering the same, but come to think that it doesn't give you much.

You (as a user) are going to work with specific node types (as
narrowed down via getKind() + as()), so I would not expect you to deal
with that super-type in your code. It'd put the declaration of those
methods into one place, which is nice, though I kinda like the
simplicity of the current Node hierarchy, with one specific sub-type
per kind.

What do others think?

>
> * Should ValidatorContext include a self type, as does Configuration?
> This would facilitate the use of custom ValidatorContext subclasses.

Ah, there's even an issue for this:
https://hibernate.atlassian.net/browse/BVAL-211.

It would have been great to make this a self-referential type from the
get-go, but at this point I'd rather leave it as is. Essentially it
only causes a small effort to providers which need to redeclare all
the ValidatorContext methods to return their own specialised sub-type.

The reason I'm reluctant to add it is that users - when upgrading
existing code to BV 2.0 - will get a raw type warning when assigning
ValidatorContext to a variable. I'd prefer to avoid this, at the cost
of the few method re-definitions to be done by providers once, which
seems acceptable.

>
> * Should Positive/Negative#strict() default true be provided as
> #orZero() default false, for commonality with
> [Past|Future]#orPresent() ?

Hum, yes, good point. I think I'd prefer that.

@Emmanuel, I vaguely remember we discussed this. Did you see a good
reason for the current default?

@All, what do you think?

>
> Matt

--Gunnar

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

From guillaume.smet at gmail.com  Wed Apr 26 05:12:19 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 26 Apr 2017 11:12:19 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
Message-ID: <CALt0+o-yMQwK_nh8fKTMrdwiajUtngwByhXSzGkkXo=L0awZ6Q@mail.gmail.com>

Hi,

On Wed, Apr 26, 2017 at 10:40 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> > * Should there be a common superinterface for
> > Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
> > the same methods?
>
> I've been wondering the same, but come to think that it doesn't give you
> much.
>
> You (as a user) are going to work with specific node types (as
> narrowed down via getKind() + as()), so I would not expect you to deal
> with that super-type in your code. It'd put the declaration of those
> methods into one place, which is nice, though I kinda like the
> simplicity of the current Node hierarchy, with one specific sub-type
> per kind.
>
> What do others think?
>

I had the exact same reasoning when I did it.

> * Should Positive/Negative#strict() default true be provided as
> > #orZero() default false, for commonality with
> > [Past|Future]#orPresent() ?
>
> Hum, yes, good point. I think I'd prefer that.
>
> @Emmanuel, I vaguely remember we discussed this. Did you see a good
> reason for the current default?
>
> @All, what do you think?
>

Matt, do you just want to change the name or also to change the default?

Currently, it's:
boolean strict() default false;
and you are supposing the default is true in your question.

Currently, we have:
- Positive/Negative: strict() default false;
- DecimalMin/DecimalMax: inclusive() default true;
- Past/Present: orPresent() default false;

I thought about proposing orZero() at the time but I didn't suggest it
because "strictly positive" makes sense.

Being strict by default would probably make more sense.

As for the name, I'm torn.

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170426/7eb7e108/attachment.html 

From mbenson at apache.org  Wed Apr 26 08:35:26 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 26 Apr 2017 07:35:26 -0500
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CALt0+o-yMQwK_nh8fKTMrdwiajUtngwByhXSzGkkXo=L0awZ6Q@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<CALt0+o-yMQwK_nh8fKTMrdwiajUtngwByhXSzGkkXo=L0awZ6Q@mail.gmail.com>
Message-ID: <CAE9L6G2iPHrT9P0qs=rd-nb0f3KPm5zXPfqMKFN2ZGunhM1jnw@mail.gmail.com>

On Apr 26, 2017 4:13 AM, "Guillaume Smet" <guillaume.smet at gmail.com> wrote:

Hi,

On Wed, Apr 26, 2017 at 10:40 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> > * Should there be a common superinterface for
> > Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
> > the same methods?
>
> I've been wondering the same, but come to think that it doesn't give you
> much.
>
> You (as a user) are going to work with specific node types (as
> narrowed down via getKind() + as()), so I would not expect you to deal
> with that super-type in your code. It'd put the declaration of those
> methods into one place, which is nice, though I kinda like the
> simplicity of the current Node hierarchy, with one specific sub-type
> per kind.
>
> What do others think?
>

I had the exact same reasoning when I did it.

> * Should Positive/Negative#strict() default true be provided as
> > #orZero() default false, for commonality with
> > [Past|Future]#orPresent() ?
>
> Hum, yes, good point. I think I'd prefer that.
>
> @Emmanuel, I vaguely remember we discussed this. Did you see a good
> reason for the current default?
>
> @All, what do you think?
>

Matt, do you just want to change the name or also to change the default?


I was speaking only of the name; however this illustrates that people may
have different expectations about what the default strict behavior would
be. #orZero() is pretty explicit.

Matt


Currently, it's:
boolean strict() default false;
and you are supposing the default is true in your question.

Currently, we have:
- Positive/Negative: strict() default false;
- DecimalMin/DecimalMax: inclusive() default true;
- Past/Present: orPresent() default false;

I thought about proposing orZero() at the time but I didn't suggest it
because "strictly positive" makes sense.

Being strict by default would probably make more sense.

As for the name, I'm torn.

-- 
Guillaume

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170426/795ac905/attachment.html 

From gunnar at hibernate.org  Thu Apr 27 17:00:50 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 27 Apr 2017 23:00:50 +0200
Subject: [bv-dev] Submitted Public Review Draft
In-Reply-To: <CADGJaX8oFwS3tnGwueuP932yARHVX=cJgUmr6hKimniffeYeSg@mail.gmail.com>
References: <CADGJaX8oFwS3tnGwueuP932yARHVX=cJgUmr6hKimniffeYeSg@mail.gmail.com>
Message-ID: <CADGJaX9KDKFYrmF+F04SHGk+bjZwFrW=oikrW9EQ8jyyjc3fGw@mail.gmail.com>

Hi all,

The Public Review draft has been posted on jcp.org now:

    https://twitter.com/gunnarmorling/status/857698930120896513

The Public Review runs until May 27th, the ballot from May 30th until
June 12th. If you are (working for) a member of the EC, please
remember your representative to vote once the ballot is on :) I'll
also be presenting the JSR in the next EC meeting in May.

Thanks everyone for making the PR draft happen!

--Gunnar




2017-04-24 17:49 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> Hi all,
>
> I've just submitted the draft of the spec for the Public Review to the
> JCP; it should be published on jcp.org later this week.
>
> You can find it at the staging environment of our website, too (that's
> the diff to 1.1):
>
>     http://staging.beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-1.1/
>
> Once it's published through jcp.org, I'll put out a short blog post to
> announce it. Please wait with tweeting etc. until then :) Assuming
> it's published on jcp.org on Wednesday, the Public Review will run
> until May 26th, followed by two weeks for the ballot (voting by the
> EC).
>
> We are going to work on some smaller details around container element
> validation next. If there's anything else which you think should be in
> there or should be changed, please speak up soon :)
>
> Cheers,
>
> --Gunnar