From emmanuel at hibernate.org  Fri Jun  2 03:35:44 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 2 Jun 2017 15:35:44 +0800
Subject: [bv-dev] Bean Validation 1.1 -> 2.0 review
Message-ID: <A9B98A62-8BF3-4ACD-A313-EE6F778AC5DE@hibernate.org>

Hey all

I could not do much but I promised Gunnar to review one last time the 1.1 -> 2.0 diff
http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/ <http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/>

I did not find much and dod not checked it all but here is at least a few things

Example 3.10: Multi-valued constraint declaration using explicit @List annotation
I?d put in the example title that it is a discouraged pattern

3.3
"composing constraints are directly given on the composed constraint? -> "composing constraints are directly given on the composed constraint (i.e. via the repeatable annotation feature)"

"refers to the left-to-right order? -> I got puzzled by that one especially as we can put them on new lines. I would say ?refers to the order in which they are declared?

Example 3.21 / 3.24
I find it odd to ahve the private method return null
Can we make it a full example?

4.1 add an exemple of non generic container usage maybe

4.4 
A value extractor for java.util.Optional:
Maybe a comment reminding that the null is passed to have no path node entry

Maybe more to come later

Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170602/6749d44c/attachment.html 

From emmanuel at hibernate.org  Fri Jun  2 05:25:44 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 2 Jun 2017 17:25:44 +0800
Subject: [bv-dev] Bean Validation 1.1 -> 2.0 review
In-Reply-To: <A9B98A62-8BF3-4ACD-A313-EE6F778AC5DE@hibernate.org>
References: <A9B98A62-8BF3-4ACD-A313-EE6F778AC5DE@hibernate.org>
Message-ID: <621BACD1-0787-4CE2-A42A-BFD915F89505@hibernate.org>

5.7.4.
> If the constraint is a generic constraint, the following rules apply. If the constraint declaration is hosted on a class or an interface, the targeted type is the class or the interface. If the constraint is hosted on a class attribute, the type of the attribute is the targeted type. If the constraint is hosted on a method (getter or non-getter) or constructor, the return type is the targeted type. If the constraint is hosted on a method or constructor parameter, the parameter type is the targetedtype. If the constraint is hosted o?

This paragraph is massive. Any chance to convert it to bullet points to make the alternatives more visual?

5.7.5

> When detecting a container element constraint or a container element marked with @Valid, the value extractor forobtaining the container?s elements must be determined.

[?] is determined (instead of must be


> On 2 Jun 2017, at 15:35, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> Hey all
> 
> I could not do much but I promised Gunnar to review one last time the 1.1 -> 2.0 diff
> http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/ <http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/>
> 
> I did not find much and dod not checked it all but here is at least a few things
> 
> Example 3.10: Multi-valued constraint declaration using explicit @List annotation
> I?d put in the example title that it is a discouraged pattern
> 
> 3.3
> "composing constraints are directly given on the composed constraint? -> "composing constraints are directly given on the composed constraint (i.e. via the repeatable annotation feature)"
> 
> "refers to the left-to-right order? -> I got puzzled by that one especially as we can put them on new lines. I would say ?refers to the order in which they are declared?
> 
> Example 3.21 / 3.24
> I find it odd to ahve the private method return null
> Can we make it a full example?
> 
> 4.1 add an exemple of non generic container usage maybe
> 
> 4.4 
> A value extractor for java.util.Optional:
> Maybe a comment reminding that the null is passed to have no path node entry
> 
> Maybe more to come later
> 
> Emmanuel
> _______________________________________________
> 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/20170602/69d20baf/attachment-0001.html 

From mbenson at apache.org  Sat Jun  3 18:28:02 2017
From: mbenson at apache.org (Matt Benson)
Date: Sat, 3 Jun 2017 17:28:02 -0500
Subject: [bv-dev] OverridesAttribute questions
Message-ID: <CAE9L6G1EARV6FMmkDzSo4ktCPZoT2F4V=QP-vZ=sLDnri6p45w@mail.gmail.com>

I have a couple of questions about @OverridesAttribute:

1. The spec says that #name() defaults to the name of the annotated
attribute, but there is actually no default value declared. Should(n't) we
declare as ""?

2. I don't have a clear understanding from the spec what the expectations
are if there is a single override specified using the default
constraintIndex value, but with multiple composing constraints of the
specified type. Does the override apply to all? Is it an error?

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

From gunnar at hibernate.org  Tue Jun  6 09:06:57 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 6 Jun 2017 15:06:57 +0200
Subject: [bv-dev] OverridesAttribute questions
In-Reply-To: <CAE9L6G1EARV6FMmkDzSo4ktCPZoT2F4V=QP-vZ=sLDnri6p45w@mail.gmail.com>
References: <CAE9L6G1EARV6FMmkDzSo4ktCPZoT2F4V=QP-vZ=sLDnri6p45w@mail.gmail.com>
Message-ID: <CADGJaX9czkaTp4h5g_fTLdak62KzivC4T8JJtr2ryzGMDorX4Q@mail.gmail.com>

Hi Matt,

2017-06-04 0:28 GMT+02:00 Matt Benson <mbenson at apache.org>:
> I have a couple of questions about @OverridesAttribute:
>
> 1. The spec says that #name() defaults to the name of the annotated
> attribute, but there is actually no default value declared. Should(n't) we
> declare as ""?

Great catch. I've filed
https://hibernate.atlassian.net/browse/BVAL-634, PR for API and spec
coming up in a bit.

>
> 2. I don't have a clear understanding from the spec what the expectations
> are if there is a single override specified using the default
> constraintIndex value, but with multiple composing constraints of the
> specified type. Does the override apply to all? Is it an error?

It's my expectation that an error would be raised. I would say it
falls into the category of

    "If the composition is invalid, e.g. [...] a single attribute
mapped to more than one source attribute [...] a
ConstraintDefinitionException is raised"

Let me know if you think that's too vague and we should add this case
more explicitly to the list of erroneous overrides discussed in the
spec.

>
> Matt

--Gunnar

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

From mbenson at apache.org  Tue Jun  6 12:17:34 2017
From: mbenson at apache.org (Matt Benson)
Date: Tue, 6 Jun 2017 11:17:34 -0500
Subject: [bv-dev] OverridesAttribute questions
In-Reply-To: <CADGJaX9czkaTp4h5g_fTLdak62KzivC4T8JJtr2ryzGMDorX4Q@mail.gmail.com>
References: <CAE9L6G1EARV6FMmkDzSo4ktCPZoT2F4V=QP-vZ=sLDnri6p45w@mail.gmail.com>
	<CADGJaX9czkaTp4h5g_fTLdak62KzivC4T8JJtr2ryzGMDorX4Q@mail.gmail.com>
Message-ID: <CAE9L6G1AvM9E+rL3we-tqFWfbqe8GbaGGNno4z=GvSJTZeFtQA@mail.gmail.com>

On Tue, Jun 6, 2017 at 8:06 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi Matt,
>
> 2017-06-04 0:28 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> I have a couple of questions about @OverridesAttribute:
>>
>> 1. The spec says that #name() defaults to the name of the annotated
>> attribute, but there is actually no default value declared. Should(n't) we
>> declare as ""?
>
> Great catch. I've filed
> https://hibernate.atlassian.net/browse/BVAL-634, PR for API and spec
> coming up in a bit.
>
>>
>> 2. I don't have a clear understanding from the spec what the expectations
>> are if there is a single override specified using the default
>> constraintIndex value, but with multiple composing constraints of the
>> specified type. Does the override apply to all? Is it an error?
>
> It's my expectation that an error would be raised. I would say it
> falls into the category of
>
>     "If the composition is invalid, e.g. [...] a single attribute
> mapped to more than one source attribute [...] a
> ConstraintDefinitionException is raised"
>
> Let me know if you think that's too vague and we should add this case
> more explicitly to the list of erroneous overrides discussed in the
> spec.
>

I suppose it is at least implicitly covered by the wording "If index
is undefined, the single constraint declaration is targeted," i.e.
"single" is an assumption which, if violated, can trigger the CDE.

Thanks,
Matt

>>
>> Matt
>
> --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  Wed Jun  7 03:25:43 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 7 Jun 2017 09:25:43 +0200
Subject: [bv-dev] Results on @Positive/@Negative poll
In-Reply-To: <CAAWA2oVQ83buOS--nKykNKXsdPtvP5Yc68tARKQuv8Pa9ontWg@mail.gmail.com>
References: <CADGJaX9qWoHuSvPDToJUmt+gtg6c8gFCf2r+KxqF0_ZcmeHgBA@mail.gmail.com>
	<CAAWA2oU4rKpksEb_5AtU+vG8x5Q2WsTR7kAt7LdKw03TkBiu_w@mail.gmail.com>
	<CADGJaX8Cx3swcE-ytSbUp9h4toKtb7RUiZm4XzmsFf0rCLLqAg@mail.gmail.com>
	<CAAWA2oVQ83buOS--nKykNKXsdPtvP5Yc68tARKQuv8Pa9ontWg@mail.gmail.com>
Message-ID: <CADGJaX-cmfPpPpQAfEafFL5MkN6tBMg=jbiwb=0kz+B0pddoCQ@mail.gmail.com>

Hi,

These are the PRs for adding @PositiveOrZero and @NegativeOrZero:

* https://github.com/beanvalidation/beanvalidation-api/pull/111
* https://github.com/beanvalidation/beanvalidation-spec/pull/183

--Gunnar


2017-05-26 18:19 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> On Fri, May 26, 2017 at 5:55 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> 2017-05-24 18:01 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
>> > The non-negative names are the way to go if we go the separate
>> > annotations
>> > route.
>>
>> Can you elaborate on your reasoning?
>
>
> OUCH, I meant the non-non-negative aka PositiveOrZero / NegativeOrZero.
> Sorry for that. It just shows how confusing negative names are :-)
>
>>
>> >  I'm not a big fan of simply listening to the masses though and I'm
>> > wondering whether these annotations pull their weight, though. I feel
>> > more
>> > inclined towards orZero, which is the second most popular choice.
>>
>> Ok, but I think it'd be bad form to first ask for feedback and then
>> not follow the expressed preference.
>
>
> I respect your reasoning. However, the difference is not statistically
> significant and we are going for the second option, which shows we're
> listening to a degree.
>
>>
>> Also I think this is mostly a question of style, it's not a black and
>> white thing.
>
>
> That's for sure.
>
> 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  Wed Jun  7 03:28:33 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 7 Jun 2017 09:28:33 +0200
Subject: [bv-dev] validation-configuration.xsd and value-extractors
In-Reply-To: <CADGJaX_QhyWiq6SdYqGtCNRxCL4iOr-mdrs0wiutmJb_j1HuAQ@mail.gmail.com>
References: <CALt0+o-cTrqZ-k=7QEZrqF_bnXXTZmsebfJ4vMLk+67gtoshfQ@mail.gmail.com>
	<CAAWA2oUbyVQEW3Mcp5vqf+bqM6aYi49DC6N_0S=dNNXyucucKg@mail.gmail.com>
	<CADGJaX_QhyWiq6SdYqGtCNRxCL4iOr-mdrs0wiutmJb_j1HuAQ@mail.gmail.com>
Message-ID: <CADGJaX9S+Z0WAcSPvERrxk6ew+jkr3ZT4p1_t-EpbLnpLxGozw@mail.gmail.com>

Hi,

Guillaume made a good case for *not* wrapping the value extractors in
validation.xml: we also don't do it for other elements in that
descriptor that can be given more than once: "constraint-mapping" and
"property". So we should leave this as is.

--Gunnar


2017-05-23 16:59 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> It's a bit more verbose, but the wrapper makes more explicit that
> multiple extractors can be given. So +1 for the wrapper.
>
> 2017-05-20 12:57 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
>> Consistency is a great argument imho, so +1 for wrapping it.
>>
>> []s
>> Michael
>>
>> On 18 May 2017 07:04, "Guillaume Smet" <guillaume.smet at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> In the current revision of the spec, the value-extractor element is at the
>>> same level as message-interpolator for instance.
>>>
>>> So, when you want to add several value-extractors, you end up having the
>>> following:
>>> <validation-config>
>>>
>>>
>>> <message-interpolator>org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.MessageInterpolatorUsingDependencyInjection</message-interpolator>
>>>
>>>
>>> <value-extractor>package.MapKeyValueExtractorUsingDependencyInjection</value-extractor>
>>>
>>> <value-extractor>package.MapValueValueExtractorUsingDependencyInjection</value-extractor>
>>>
>>> </validation-config>
>>>
>>> I was thinking that we should maybe wrap it into a value-extractors
>>> element. It would be nicer and more consistent with the usual conventions.
>>>
>>> What do you all think about it?
>>>
>>> --
>>> 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

From gunnar at hibernate.org  Thu Jun  8 04:18:42 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 8 Jun 2017 10:18:42 +0200
Subject: [bv-dev] Bean Validation 1.1 -> 2.0 review
In-Reply-To: <A9B98A62-8BF3-4ACD-A313-EE6F778AC5DE@hibernate.org>
References: <A9B98A62-8BF3-4ACD-A313-EE6F778AC5DE@hibernate.org>
Message-ID: <CADGJaX-0f5pqK+BBQymyz3WM4ReOxvDJN-piC6-u1Poa9z=MNw@mail.gmail.com>

Thanks! PR addressing your remarks is coming up.

2017-06-02 9:35 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> Hey all
>
> I could not do much but I promised Gunnar to review one last time the 1.1 ->
> 2.0 diff
> http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/
>
> I did not find much and dod not checked it all but here is at least a few
> things
>
> Example 3.10: Multi-valued constraint declaration using explicit @List
> annotation
> I?d put in the example title that it is a discouraged pattern

Ok.

>
> 3.3
> "composing constraints are directly given on the composed constraint? ->
> "composing constraints are directly given on the composed constraint (i.e.
> via the repeatable annotation feature)"

Ok.
>
> "refers to the left-to-right order? -> I got puzzled by that one especially
> as we can put them on new lines. I would say ?refers to the order in which
> they are declared?

"left-to-right-order" is a term used by the JLS, I think it's fine to
use it here as well.

>
> Example 3.21 / 3.24
> I find it odd to ahve the private method return null
> Can we make it a full example?

Ok, this example was pre-existing from 1.x times :) Replacing it with
a complete example.

>
> 4.1 add an exemple of non generic container usage maybe

There is an example for this (OptionalInt) in 4.4 (which contains all
the examples for this chapter).

>
> 4.4
> A value extractor for java.util.Optional:
> Maybe a comment reminding that the null is passed to have no path node entry

Ok.

>
> Maybe more to come later
>
> Emmanuel
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From gunnar at hibernate.org  Thu Jun  8 04:37:24 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 8 Jun 2017 10:37:24 +0200
Subject: [bv-dev] Bean Validation 1.1 -> 2.0 review
In-Reply-To: <621BACD1-0787-4CE2-A42A-BFD915F89505@hibernate.org>
References: <A9B98A62-8BF3-4ACD-A313-EE6F778AC5DE@hibernate.org>
	<621BACD1-0787-4CE2-A42A-BFD915F89505@hibernate.org>
Message-ID: <CADGJaX-YsU8C8xTOZ3TX=fL8Ho=tKYgELanT-1ymFocKSAeYEg@mail.gmail.com>

2017-06-02 11:25 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> 5.7.4.
>
> If the constraint is a generic constraint, the following rules apply. If the
> constraint declaration is hosted on a class or an interface, the targeted
> type is the class or the interface. If the constraint is hosted on a class
> attribute, the type of the attribute is the targeted type. If the constraint
> is hosted on a method (getter or non-getter) or constructor, the return type
> is the targeted type. If the constraint is hosted on a method or constructor
> parameter, the parameter type is the targetedtype. If the constraint is
> hosted o?
>
>
> This paragraph is massive. Any chance to convert it to bullet points to make
> the alternatives more visual?

Good idea.

>
> 5.7.5
>
> When detecting a container element constraint or a container element marked
> with @Valid, the value extractor forobtaining the container?s elements must
> be determined.
>
>
> [?] is determined (instead of must be

Changing it into

"When detecting a container element constraint or a container element
marked with `@Valid`, a value extractor must be determined so that the
elements can be obtained from that container."

I've prepared PR
https://github.com/beanvalidation/beanvalidation-spec/pull/186 to
address your remarks.

>
>
> On 2 Jun 2017, at 15:35, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> Hey all
>
> I could not do much but I promised Gunnar to review one last time the 1.1 ->
> 2.0 diff
> http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/
>
> I did not find much and dod not checked it all but here is at least a few
> things
>
> Example 3.10: Multi-valued constraint declaration using explicit @List
> annotation
> I?d put in the example title that it is a discouraged pattern
>
> 3.3
> "composing constraints are directly given on the composed constraint? ->
> "composing constraints are directly given on the composed constraint (i.e.
> via the repeatable annotation feature)"
>
> "refers to the left-to-right order? -> I got puzzled by that one especially
> as we can put them on new lines. I would say ?refers to the order in which
> they are declared?
>
> Example 3.21 / 3.24
> I find it odd to ahve the private method return null
> Can we make it a full example?
>
> 4.1 add an exemple of non generic container usage maybe
>
> 4.4
> A value extractor for java.util.Optional:
> Maybe a comment reminding that the null is passed to have no path node entry
>
> Maybe more to come later
>
> Emmanuel
> _______________________________________________
> 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  Tue Jun 13 10:41:47 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 13 Jun 2017 16:41:47 +0200
Subject: [bv-dev] Caching of provider resolvers
Message-ID: <CADGJaX9JcbXELU=q5HCaXR=fbHZ-2aA05kgwP93NuKzcYmVynw@mail.gmail.com>

All,

We've come across an issue related to bootstrapping BV providers in
application servers and I'd be interested in your ideas around it.

The issue (BVAL-551 [1]) is about the javax.validation.Validation
class and the way it loads -- and caches -- validation providers.
j.v.Validation is essentially the only class in the entire API with
some actual implementation, so it's a bit special in that way.

The validation-api.jar we provide alongside the RI maintains a cache
of resolved validation providers [2], this is to avoid repeated
look-ups via the service loader. In order to avoid any memory leaks,
this is implemented as a weak map with soft references as values. This
guarantees this map to be freed before an OutOfMemoryError occurs.
Nevertheless this can cause the memory to be retained for a long time,
esp. in an application server it may cause a reference to application
class loaders be retained if a validation provider has been obtained
from a deployment (again, eventually, that reference will be
released).

For that case it'd be beneficial to have a way to pro-actively flush
that cache upon application undeployment. Now the thing is that the BV
API and the docs of j.v.Validation don't make any assumption on the
implementation and naturally there's no public notion of such caching
part of the API. Thus my preferred way for addressing this issue is to
declare a non-public method such as releaseProviderCache() in
j.v.Validation of our validation-api.jar. This method wouldn't be part
of the specified API. Interested application servers could call that
method reflectively as needed.

In a future version of BV we could consider to make this a public API,
e.g. there could be Validation#getDefaultProviderResolver() and a new
default method ValidationProviderResolver#release() which could be
called to release any resources hold by a provider resolver (the cache
is hold within the default implementation of ProviderResolver).
Theoretically, this could also added to BV 2.0, but I feel it's a bit
rushed and I'd rather gather some experiences with this very special
purpose functionality before committing to it as part of the spec.

Any thoughts on this one would be highly welcomed. Does anyone know
how Apache BVAL deals with this (via geronimo-validation-spec), e.g.
within TomEE?

Thanks,

--Gunnar

[1] https://hibernate.atlassian.net/browse/BVAL-551
[2] https://github.com/beanvalidation/beanvalidation-api/blob/master/src/main/java/javax/validation/Validation.java#L317

From moltenma at gmail.com  Tue Jun 13 17:45:17 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Tue, 13 Jun 2017 23:45:17 +0200
Subject: [bv-dev] Caching of provider resolvers
In-Reply-To: <CADGJaX9JcbXELU=q5HCaXR=fbHZ-2aA05kgwP93NuKzcYmVynw@mail.gmail.com>
References: <CADGJaX9JcbXELU=q5HCaXR=fbHZ-2aA05kgwP93NuKzcYmVynw@mail.gmail.com>
Message-ID: <CANUPYM0a=Lxj+bBjAYqUfnWQS3Wymcf0OhNBU0=wvRwOoKwxhg@mail.gmail.com>

Hi Gunnar,

> how Apache BVAL deals with this (via geronimo-validation-spec), e.g.
> within TomEE?

Not sure if it can help. It seems that there is no caching:
https://github.com/apache/bval/blob/bval-11/bval-jsr/
src/main/java/org/apache/bval/jsr/DefaultValidationProviderResolver.java


> Nevertheless this can cause the memory to be retained for a long time,
> esp. in an application server it may cause a reference to application
> class loaders be retained if a validation provider has been obtained
> from a deployment

I think in most of the use cases there is one application per
server/container and the server/container is restarted at each deploy. For
these cases there is no issue.

> Thus my preferred way for addressing this issue is to
> declare a non-public method such as releaseProviderCache()
> [...] In a future version of BV we could consider to make this a public
API,

Ok for me. This is not a regression from BV 1.1 and there is a workaround
until the next version of BV.

> [Scott, from JIRA] My vote is to keep good performance by default (e.g.
keep the caching) but address the problem that we are caching things that
we > don't know when to release from the cache.

Totally agree.


Marco


On Tue, Jun 13, 2017 at 4:41 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> All,
>
> We've come across an issue related to bootstrapping BV providers in
> application servers and I'd be interested in your ideas around it.
>
> The issue (BVAL-551 [1]) is about the javax.validation.Validation
> class and the way it loads -- and caches -- validation providers.
> j.v.Validation is essentially the only class in the entire API with
> some actual implementation, so it's a bit special in that way.
>
> The validation-api.jar we provide alongside the RI maintains a cache
> of resolved validation providers [2], this is to avoid repeated
> look-ups via the service loader. In order to avoid any memory leaks,
> this is implemented as a weak map with soft references as values. This
> guarantees this map to be freed before an OutOfMemoryError occurs.
> Nevertheless this can cause the memory to be retained for a long time,
> esp. in an application server it may cause a reference to application
> class loaders be retained if a validation provider has been obtained
> from a deployment (again, eventually, that reference will be
> released).
>
> For that case it'd be beneficial to have a way to pro-actively flush
> that cache upon application undeployment. Now the thing is that the BV
> API and the docs of j.v.Validation don't make any assumption on the
> implementation and naturally there's no public notion of such caching
> part of the API. Thus my preferred way for addressing this issue is to
> declare a non-public method such as releaseProviderCache() in
> j.v.Validation of our validation-api.jar. This method wouldn't be part
> of the specified API. Interested application servers could call that
> method reflectively as needed.
>
> In a future version of BV we could consider to make this a public API,
> e.g. there could be Validation#getDefaultProviderResolver() and a new
> default method ValidationProviderResolver#release() which could be
> called to release any resources hold by a provider resolver (the cache
> is hold within the default implementation of ProviderResolver).
> Theoretically, this could also added to BV 2.0, but I feel it's a bit
> rushed and I'd rather gather some experiences with this very special
> purpose functionality before committing to it as part of the spec.
>
> Any thoughts on this one would be highly welcomed. Does anyone know
> how Apache BVAL deals with this (via geronimo-validation-spec), e.g.
> within TomEE?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/BVAL-551
> [2] https://github.com/beanvalidation/beanvalidation-api/blob/
> master/src/main/java/javax/validation/Validation.java#L317
> _______________________________________________
> 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/20170613/e9c241c4/attachment.html 

From andrei at sereda.cc  Wed Jun 14 00:12:37 2017
From: andrei at sereda.cc (Andrei Sereda)
Date: Wed, 14 Jun 2017 00:12:37 -0400
Subject: [bv-dev] support for non-standard Java beans
Message-ID: <CACjfWpcYn6imYK1FsWt+JTNy2FByF4asp3oKqGKherrArpyf9Q@mail.gmail.com>

Hello,

Apologies  if I hijack this mailing list. Please redirect me to right DL /
forum, if it is the case.

I would like to inquire if custom method resolution is within the scope of
the spec (or exists already) for beans which don't exactly follow JavaBean
convention. By custom, I mean name() vs getName().

I've noticed, lately, the trend to use code generators (Immutables
<https://immutables.github.io/>, FreeBuilder
<http://freebuilder.inferred.org/>, AutoValue
<https://github.com/google/auto/blob/master/value/userguide/index.md> etc.)
for domain entities. By default they all use name() for getters (instead of
getName()) :

@FreeBuilder public interface Person {
@NotBlank String name();
@Min(16) int age(); .... }

It would be nice if BeanValidation could support such use-case via
pluggable (getter / setter) method resolver (for example).

Associated JIRA  ticket HV-1363
<https://hibernate.atlassian.net/browse/HV-1363>

Thanks in advance,
Andrei.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170614/24966057/attachment.html 

From gunnar at hibernate.org  Wed Jun 14 02:35:07 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 14 Jun 2017 08:35:07 +0200
Subject: [bv-dev] support for non-standard Java beans
In-Reply-To: <CACjfWpcYn6imYK1FsWt+JTNy2FByF4asp3oKqGKherrArpyf9Q@mail.gmail.com>
References: <CACjfWpcYn6imYK1FsWt+JTNy2FByF4asp3oKqGKherrArpyf9Q@mail.gmail.com>
Message-ID: <CADGJaX_hNtP9co9D=gy53+vcnBxGcyejKoBd6_wKBYX6fWyNkQ@mail.gmail.com>

Hi Andrei,

You've come to the right place to discuss such proposals.

Supporting other models than JavaBeans is an interesting idea, we've
also been thinking about it as part of the reference implementation.
It's too late for BV 2.0, but it's definitely something I could
envision in a future spec revision.

> Associated JIRA  ticket HV-1363

Thanks; we should definitely explore that within the RI.

There's also https://hibernate.atlassian.net/browse/HV-1000 which
takes the thought a bit further and aims at supporting models not
backed by POJOs at all, but e.g. maps (with key/value pairs as
properties), JSON strings etc. Naturally, annotations couldn't be used
as metadata source for such models, instead constraints would have to
be declared programmatically.

Perhaps you'd be interested in contributing and exploring the property
resolver SPI you suggest?

--Gunnar



2017-06-14 6:12 GMT+02:00 Andrei Sereda <andrei at sereda.cc>:
> Hello,
>
> Apologies  if I hijack this mailing list. Please redirect me to right DL /
> forum, if it is the case.
>
> I would like to inquire if custom method resolution is within the scope of
> the spec (or exists already) for beans which don't exactly follow JavaBean
> convention. By custom, I mean name() vs getName().
>
> I've noticed, lately, the trend to use code generators (Immutables,
> FreeBuilder, AutoValue etc.) for domain entities. By default they all use
> name() for getters (instead of getName()) :
>
> @FreeBuilder public interface Person {
> @NotBlank String name();
> @Min(16) int age(); .... }
>
> It would be nice if BeanValidation could support such use-case via pluggable
> (getter / setter) method resolver (for example).
>
> Associated JIRA  ticket HV-1363
>
> Thanks in advance,
> Andrei.
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Thu Jun 15 07:16:37 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 15 Jun 2017 13:16:37 +0200
Subject: [bv-dev] Node#isInIterable() for arrays
Message-ID: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>

Hi all,

On our road to the Proposed Final Draft (more on that in a separate
mail a bit), we've almost closed out all the relevant issues.

One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552
which is about inconsistent behaviour of Node#isInIterable() when it
comes to arrays. The spec says this:

    "isInIterable() returns true if the node represents an object
contained in an Iterable or in a Map, false otherwise."

Whereas the TCK has a test case which expects true to be returned for
arrays, too [1]. Naturally, that's how the RI (and any other
TCK-compliant implementation) implements this.

Now my question is, should we simply change the spec and say

        "isInIterable() returns true if the node represents an object
contained in an Iterable, Map or an array, false otherwise."

Given that maps are considered already, the method has to be about
"things that are iterable" and not java.lang.Iterable (which j.u.Map
doesn't extend). So considering arrays there seems consistent.

Or do you, Emmanuel, remember a reason for the current specification
and it's actually a bug in the TCK?

Thanks,

--Gunnar

[1] https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/validation/PropertyPathTest.java#L196

From mbenson at apache.org  Thu Jun 15 11:15:57 2017
From: mbenson at apache.org (Matt Benson)
Date: Thu, 15 Jun 2017 10:15:57 -0500
Subject: [bv-dev] Spec question on constructors
Message-ID: <CAE9L6G3ZEkxLz_j1ZvAJgumcg68BNT_Rrr-X=dVRfsQfQqfDXA@mail.gmail.com>

The last paragraph of section 5.6.5 states that inheritance rules do
not apply to constructors as these are not inherited. However, the
Javadoc of BeanDescriptor#getConstraintsForConstructor(Class<?>...)
says "Constructor of super types are considered." While it could be
possible to implement this, what would be the point? These notions
feel at odds with one another.

Thanks,
Matt

From mbenson at apache.org  Thu Jun 15 11:38:29 2017
From: mbenson at apache.org (Matt Benson)
Date: Thu, 15 Jun 2017 10:38:29 -0500
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
Message-ID: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>

The various descriptor types return constraint information from the
entire hierarchy by default. However, in thinking about this I quickly
encountered a puzzle which I cannot solve using the current version of
the specification. Consider:

public interface User {
  Set<@NotEmpty String> getRoles();
}

public class Roles implements Set<String> {
 ...
}

public class UserImpl implements User {
  @Override
  public Roles getRoles();
}

What should the metadata of UserImpl provide? The Iterable value
extractor is applicable to Roles, but because the return value of the
getter has been narrowed, there is no type parameter at this point in
the hierarchy. It seems strange for a PropertyDescriptor of type Roles
to return a ContainerElementTypeDescriptor with index 0. This example
would AFAICT apply to e.g. javafx StringProperty as well, so it's
probably a question we need to resolve, unless I have missed something
that should be obvious. I think this could be solved if the CETD were
to explicitly specify the type with which its argument index is
associated. The alternative would be to require a custom
ValueExtractor? This seems cumbersome and unnecessary.

Thanks,
Matt

From christian at kaltepoth.de  Thu Jun 15 12:20:26 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Thu, 15 Jun 2017 18:20:26 +0200
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
Message-ID: <CAEXeC6yo_eWnK2RDWb4NBXFxv=7FyaZNKn6tr=2hDERqarKNYw@mail.gmail.com>

Supporting arrays as well sounds reasonable to me. Unless there is any good
argument against it.

2017-06-15 13:16 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> Hi all,
>
> On our road to the Proposed Final Draft (more on that in a separate
> mail a bit), we've almost closed out all the relevant issues.
>
> One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552
> which is about inconsistent behaviour of Node#isInIterable() when it
> comes to arrays. The spec says this:
>
>     "isInIterable() returns true if the node represents an object
> contained in an Iterable or in a Map, false otherwise."
>
> Whereas the TCK has a test case which expects true to be returned for
> arrays, too [1]. Naturally, that's how the RI (and any other
> TCK-compliant implementation) implements this.
>
> Now my question is, should we simply change the spec and say
>
>         "isInIterable() returns true if the node represents an object
> contained in an Iterable, Map or an array, false otherwise."
>
> Given that maps are considered already, the method has to be about
> "things that are iterable" and not java.lang.Iterable (which j.u.Map
> doesn't extend). So considering arrays there seems consistent.
>
> Or do you, Emmanuel, remember a reason for the current specification
> and it's actually a bug in the TCK?
>
> Thanks,
>
> --Gunnar
>
> [1] https://github.com/beanvalidation/beanvalidation-
> tck/blob/master/tests/src/main/java/org/hibernate/
> beanvalidation/tck/tests/validation/PropertyPathTest.java#L196
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170615/28b2be33/attachment.html 

From mbenson at apache.org  Thu Jun 15 13:31:14 2017
From: mbenson at apache.org (Matt Benson)
Date: Thu, 15 Jun 2017 12:31:14 -0500
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <CAEXeC6yo_eWnK2RDWb4NBXFxv=7FyaZNKn6tr=2hDERqarKNYw@mail.gmail.com>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
	<CAEXeC6yo_eWnK2RDWb4NBXFxv=7FyaZNKn6tr=2hDERqarKNYw@mail.gmail.com>
Message-ID: <CAE9L6G3RaPR5ye0qNARgpB3wr2S1ypTEh+7MqXAZihts4eRwRw@mail.gmail.com>

+1

Matt

On Thu, Jun 15, 2017 at 11:20 AM, Christian Kaltepoth
<christian at kaltepoth.de> wrote:
> Supporting arrays as well sounds reasonable to me. Unless there is any good
> argument against it.
>
> 2017-06-15 13:16 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>>
>> Hi all,
>>
>> On our road to the Proposed Final Draft (more on that in a separate
>> mail a bit), we've almost closed out all the relevant issues.
>>
>> One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552
>> which is about inconsistent behaviour of Node#isInIterable() when it
>> comes to arrays. The spec says this:
>>
>>     "isInIterable() returns true if the node represents an object
>> contained in an Iterable or in a Map, false otherwise."
>>
>> Whereas the TCK has a test case which expects true to be returned for
>> arrays, too [1]. Naturally, that's how the RI (and any other
>> TCK-compliant implementation) implements this.
>>
>> Now my question is, should we simply change the spec and say
>>
>>         "isInIterable() returns true if the node represents an object
>> contained in an Iterable, Map or an array, false otherwise."
>>
>> Given that maps are considered already, the method has to be about
>> "things that are iterable" and not java.lang.Iterable (which j.u.Map
>> doesn't extend). So considering arrays there seems consistent.
>>
>> Or do you, Emmanuel, remember a reason for the current specification
>> and it's actually a bug in the TCK?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>> https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/validation/PropertyPathTest.java#L196
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Thu Jun 15 14:21:42 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Thu, 15 Jun 2017 15:21:42 -0300
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <CAE9L6G3RaPR5ye0qNARgpB3wr2S1ypTEh+7MqXAZihts4eRwRw@mail.gmail.com>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
	<CAEXeC6yo_eWnK2RDWb4NBXFxv=7FyaZNKn6tr=2hDERqarKNYw@mail.gmail.com>
	<CAE9L6G3RaPR5ye0qNARgpB3wr2S1ypTEh+7MqXAZihts4eRwRw@mail.gmail.com>
Message-ID: <CAAWA2oXiu88Tbdbu59UM1ct9MhVWPUjnGz_5XNVLMLpNUm6Hpw@mail.gmail.com>

Should we include Stream as well?

Regards,
Michael

On 15 Jun 2017 14:55, "Matt Benson" <mbenson at apache.org> wrote:

> +1
>
> Matt
>
> On Thu, Jun 15, 2017 at 11:20 AM, Christian Kaltepoth
> <christian at kaltepoth.de> wrote:
> > Supporting arrays as well sounds reasonable to me. Unless there is any
> good
> > argument against it.
> >
> > 2017-06-15 13:16 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> >>
> >> Hi all,
> >>
> >> On our road to the Proposed Final Draft (more on that in a separate
> >> mail a bit), we've almost closed out all the relevant issues.
> >>
> >> One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552
> >> which is about inconsistent behaviour of Node#isInIterable() when it
> >> comes to arrays. The spec says this:
> >>
> >>     "isInIterable() returns true if the node represents an object
> >> contained in an Iterable or in a Map, false otherwise."
> >>
> >> Whereas the TCK has a test case which expects true to be returned for
> >> arrays, too [1]. Naturally, that's how the RI (and any other
> >> TCK-compliant implementation) implements this.
> >>
> >> Now my question is, should we simply change the spec and say
> >>
> >>         "isInIterable() returns true if the node represents an object
> >> contained in an Iterable, Map or an array, false otherwise."
> >>
> >> Given that maps are considered already, the method has to be about
> >> "things that are iterable" and not java.lang.Iterable (which j.u.Map
> >> doesn't extend). So considering arrays there seems consistent.
> >>
> >> Or do you, Emmanuel, remember a reason for the current specification
> >> and it's actually a bug in the TCK?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> >> [1]
> >> https://github.com/beanvalidation/beanvalidation-
> tck/blob/master/tests/src/main/java/org/hibernate/
> beanvalidation/tck/tests/validation/PropertyPathTest.java#L196
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> >
> >
> > --
> > Christian Kaltepoth
> > Blog: http://blog.kaltepoth.de/
> > Twitter: http://twitter.com/chkal
> > GitHub: https://github.com/chkal
> >
> >
> > _______________________________________________
> > 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/20170615/f02ca76d/attachment-0001.html 

From gunnar at hibernate.org  Thu Jun 15 14:26:29 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 15 Jun 2017 20:26:29 +0200
Subject: [bv-dev] Towards Proposed Final Draft and Final Approval Ballot
Message-ID: <CADGJaX-X5LwBjOS2FTbneGCjMh4Jwz2fC-OdVNu9NrTAeMifCA@mail.gmail.com>

Hey all,

As you probably noticed, Bean Validation 2.0 has passed the Public
Review successfully [1]. That's a very important step and a great
result -- thanks a lot for all your work to make it happen!

There's not much time to celebrate (yet) though, as the timeline -- as
dictated by the overall schedule for Java EE 8 -- going forward to the
Final version is tight.

We made a good dent on clarifications and clean-ups on the spec and
the TCK in the last days (kudos to Guillaume!!!). The remaining open
issues assigned to 2.0.0.CR1 (= PFD) and 2.0-next (=Final Approval
Ballot version) are mostly cosmetics and administrative things [2]. So
I would like to submit the Proposed Final Draft to the JCP mid next
week and submit to the Final Approval Ballot at the beginning of July.

Please let me know if you have any objections on that planning or see
any further issues we should address prior to the Final.

Also, if you haven't done so yet, it'd be a great thing if you could
spend some time and check out the diff with all the changes since Bean
Validation 1.1:

    http://beanvalidation.org/latest-draft/diff-to-1.1/

Any feedback on ambiguities, missing or incorrect pieces, typos,
formatting issues etc. is welcomed very much. If you let me know about
your findings by Monday, I'll have a chance to incorporate any
suggestions for the PFD.

Thanks a lot and looking forward to finalising Bean Validation 2.0,

--Gunnar

[1] https://www.jcp.org/en/jsr/results?id=5998
[2] https://hibernate.atlassian.net/issues/?jql=project%20%3D%20BVAL%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20fixVersion%20in%20(2.0-next%2C%202.0.0.CR1)%20ORDER%20BY%20status%20DESC

From emmanuel at hibernate.org  Fri Jun 16 03:08:49 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 16 Jun 2017 09:08:49 +0200
Subject: [bv-dev] Towards Proposed Final Draft and Final Approval Ballot
In-Reply-To: <CADGJaX-X5LwBjOS2FTbneGCjMh4Jwz2fC-OdVNu9NrTAeMifCA@mail.gmail.com>
References: <CADGJaX-X5LwBjOS2FTbneGCjMh4Jwz2fC-OdVNu9NrTAeMifCA@mail.gmail.com>
Message-ID: <81D0FBB2-AF97-4FD9-A49C-250A0466E0B1@hibernate.org>

Please EG members, this is the time before it?s too late!

Emmanuel

> On 15 Jun 2017, at 20:26, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> 
> Also, if you haven't done so yet, it'd be a great thing if you could
> spend some time and check out the diff with all the changes since Bean
> Validation 1.1:
> 
>    http://beanvalidation.org/latest-draft/diff-to-1.1/ <http://beanvalidation.org/latest-draft/diff-to-1.1/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170616/025972de/attachment.html 

From gunnar at hibernate.org  Fri Jun 16 03:43:33 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 16 Jun 2017 09:43:33 +0200
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
Message-ID: <CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>

Hi Matt,

Thanks for bringing this up!

I think adding ContainerElementTypeDescriptor#getContainerClass() is
one thing needed, but it's not enough. Currently we have
List<ContainerElementTypeDescriptor> getContainerElementTypes() on
PropertyDescriptor etc. which returns the container element
descriptors in the order of type arguments. This also doesn't really
fit for User#getRoles().

So we could make this a Set<ContainerElementTypeDescriptor> instead,
and then each element from that set exposes containerClass and
typeArgumentIndex as you suggest.

It's getting a bit tricky though to get the effective set of all
container element constraints. Eg. say we have:

    public interface IUserBase {
        Set<@NotBlank String> getRoles();
    }

    public interface IUser extends IUserBase {
        Set<@NotEmpty String> getRoles();
    }

    public class UserImpl implements IUser {
        Roles getRoles();
    }

Then when querying

    validator.getConstraintsForClass( IUser.class )
        .getConstraintsForProperty( "roles" )
        .getContainerElementTypes();

We'd get a set with these elements:

    - ContainerElementDescriptor(containerClass=IUser.class,
typeArgumentIndex=0, constraints={(type=NotEmpty,
defined=DEFINED_LOCALLY), (type=NotBlank,
defined=DEFINED_IN_HIERARCHY)}
    - ContainerElementDescriptor(containerClass=User.class,
typeArgumentIndex=0, constraints={(type=NotBlank, defined=
DEFINED_LOCALLY)}

The descriptor for IUser would have to return the inherited @NotBlank
as per the defined semantics of getConstraintDescriptors(). So one
would have to examine all ContainerElementDescriptors and just collect
the ones that are DEFINED_LOCALLY to have the effective set without
duplicates.

The alternative would be to explicitly redeclare
getConstraintDescriptors() for ContainerElementDescriptor and say that
it doesn't expose constraints from the hierarchy. But this would make
it very difficult for the user to find all those constraints applying
to a given container element type (esp. as type arguments could switch
their order in the hierarchy). So that'd not be my preferred route.

WDYT?

I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.

--Gunnar


2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
> The various descriptor types return constraint information from the
> entire hierarchy by default. However, in thinking about this I quickly
> encountered a puzzle which I cannot solve using the current version of
> the specification. Consider:
>
> public interface User {
>   Set<@NotEmpty String> getRoles();
> }
>
> public class Roles implements Set<String> {
>  ...
> }
>
> public class UserImpl implements User {
>   @Override
>   public Roles getRoles();
> }
>
> What should the metadata of UserImpl provide? The Iterable value
> extractor is applicable to Roles, but because the return value of the
> getter has been narrowed, there is no type parameter at this point in
> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
> to return a ContainerElementTypeDescriptor with index 0. This example
> would AFAICT apply to e.g. javafx StringProperty as well, so it's
> probably a question we need to resolve, unless I have missed something
> that should be obvious. I think this could be solved if the CETD were
> to explicitly specify the type with which its argument index is
> associated. The alternative would be to require a custom
> ValueExtractor? This seems cumbersome and unnecessary.
>
> Thanks,
> Matt
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From emmanuel at hibernate.org  Fri Jun 16 05:35:19 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 16 Jun 2017 11:35:19 +0200
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
Message-ID: <2897EFD5-EABA-44FB-8637-6861426B0D86@hibernate.org>

I looked at the spec and especially with the method inContainer

Is the pattern supposed to always be inContainer(?).inIterable()?
I suppose no because the spec did not have inContainer before.
So what does it mean, when inIterable() is used, then a inContainer call is implied?

Back to the core subject, I can?t quite remember why I added Map to the list of isIterable() elements.
I suppose that if we follow that path, any container that returns multiple elements should return isIterable == true (i.e. containers that call iterableValue, indexedValue or keyedValue.
So I?d add arrays and any multi-valued container to the definition of isIterable()

Emmanuel

> On 15 Jun 2017, at 13:16, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi all,
> 
> On our road to the Proposed Final Draft (more on that in a separate
> mail a bit), we've almost closed out all the relevant issues.
> 
> One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552
> which is about inconsistent behaviour of Node#isInIterable() when it
> comes to arrays. The spec says this:
> 
>    "isInIterable() returns true if the node represents an object
> contained in an Iterable or in a Map, false otherwise."
> 
> Whereas the TCK has a test case which expects true to be returned for
> arrays, too [1]. Naturally, that's how the RI (and any other
> TCK-compliant implementation) implements this.
> 
> Now my question is, should we simply change the spec and say
> 
>        "isInIterable() returns true if the node represents an object
> contained in an Iterable, Map or an array, false otherwise."
> 
> Given that maps are considered already, the method has to be about
> "things that are iterable" and not java.lang.Iterable (which j.u.Map
> doesn't extend). So considering arrays there seems consistent.
> 
> Or do you, Emmanuel, remember a reason for the current specification
> and it's actually a bug in the TCK?
> 
> Thanks,
> 
> --Gunnar
> 
> [1] https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/validation/PropertyPathTest.java#L196
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev



From gunnar at hibernate.org  Fri Jun 16 05:44:46 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 16 Jun 2017 11:44:46 +0200
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <CAAWA2oXiu88Tbdbu59UM1ct9MhVWPUjnGz_5XNVLMLpNUm6Hpw@mail.gmail.com>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
	<CAEXeC6yo_eWnK2RDWb4NBXFxv=7FyaZNKn6tr=2hDERqarKNYw@mail.gmail.com>
	<CAE9L6G3RaPR5ye0qNARgpB3wr2S1ypTEh+7MqXAZihts4eRwRw@mail.gmail.com>
	<CAAWA2oXiu88Tbdbu59UM1ct9MhVWPUjnGz_5XNVLMLpNUm6Hpw@mail.gmail.com>
Message-ID: <CADGJaX-hSA3x0XazSYe=a1wYS8mhnPxhKRUQ8aSjZ2KRQ3tsWg@mail.gmail.com>

2017-06-15 20:21 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> Should we include Stream as well?

I don't think we should, as we don't mention or support streams at
this point at all.

In 2.1 we could mandate a built-in extractor for Stream, stating that
it has to call ValueReceiver#iterableValue().

>
> Regards,
> Michael
>
> On 15 Jun 2017 14:55, "Matt Benson" <mbenson at apache.org> wrote:
>>
>> +1
>>
>> Matt
>>
>> On Thu, Jun 15, 2017 at 11:20 AM, Christian Kaltepoth
>> <christian at kaltepoth.de> wrote:
>> > Supporting arrays as well sounds reasonable to me. Unless there is any
>> > good
>> > argument against it.
>> >
>> > 2017-06-15 13:16 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>> >>
>> >> Hi all,
>> >>
>> >> On our road to the Proposed Final Draft (more on that in a separate
>> >> mail a bit), we've almost closed out all the relevant issues.
>> >>
>> >> One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552
>> >> which is about inconsistent behaviour of Node#isInIterable() when it
>> >> comes to arrays. The spec says this:
>> >>
>> >>     "isInIterable() returns true if the node represents an object
>> >> contained in an Iterable or in a Map, false otherwise."
>> >>
>> >> Whereas the TCK has a test case which expects true to be returned for
>> >> arrays, too [1]. Naturally, that's how the RI (and any other
>> >> TCK-compliant implementation) implements this.
>> >>
>> >> Now my question is, should we simply change the spec and say
>> >>
>> >>         "isInIterable() returns true if the node represents an object
>> >> contained in an Iterable, Map or an array, false otherwise."
>> >>
>> >> Given that maps are considered already, the method has to be about
>> >> "things that are iterable" and not java.lang.Iterable (which j.u.Map
>> >> doesn't extend). So considering arrays there seems consistent.
>> >>
>> >> Or do you, Emmanuel, remember a reason for the current specification
>> >> and it's actually a bug in the TCK?
>> >>
>> >> Thanks,
>> >>
>> >> --Gunnar
>> >>
>> >> [1]
>> >>
>> >> https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/validation/PropertyPathTest.java#L196
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> >
>> >
>> > --
>> > Christian Kaltepoth
>> > Blog: http://blog.kaltepoth.de/
>> > Twitter: http://twitter.com/chkal
>> > GitHub: https://github.com/chkal
>> >
>> >
>> > _______________________________________________
>> > 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 Jun 16 06:48:35 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 16 Jun 2017 12:48:35 +0200
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <2897EFD5-EABA-44FB-8637-6861426B0D86@hibernate.org>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
	<2897EFD5-EABA-44FB-8637-6861426B0D86@hibernate.org>
Message-ID: <CADGJaX_1aPVi1mbgbkkH81T6OGwPzHeNGUtrXJxpM0D71dtUjw@mail.gmail.com>

2017-06-16 11:35 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> I looked at the spec and especially with the method inContainer
>
> Is the pattern supposed to always be inContainer(?).inIterable()?
> I suppose no because the spec did not have inContainer before.

inIterable() could also follow to addContainerElementNode().

> So what does it mean, when inIterable() is used, then a inContainer call is implied?

It is recommended to not call inIterable() without calling
inContainer() or addContainerElementNode() before, as otherwise
containerClass and typeArgumentIndex will be missing from the
resulting path node.

>
> Back to the core subject, I can?t quite remember why I added Map to the list of isIterable() elements.
> I suppose that if we follow that path, any container that returns multiple elements should return isIterable == true (i.e. containers that call iterableValue, indexedValue or keyedValue.
> So I?d add arrays and any multi-valued container to the definition of isIterable()

Ok, cool. I'll add arrays then.

For other containers, I'd add this when adding more built-in
containers to the spec in the future.

>
> Emmanuel
>
>> On 15 Jun 2017, at 13:16, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi all,
>>
>> On our road to the Proposed Final Draft (more on that in a separate
>> mail a bit), we've almost closed out all the relevant issues.
>>
>> One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552
>> which is about inconsistent behaviour of Node#isInIterable() when it
>> comes to arrays. The spec says this:
>>
>>    "isInIterable() returns true if the node represents an object
>> contained in an Iterable or in a Map, false otherwise."
>>
>> Whereas the TCK has a test case which expects true to be returned for
>> arrays, too [1]. Naturally, that's how the RI (and any other
>> TCK-compliant implementation) implements this.
>>
>> Now my question is, should we simply change the spec and say
>>
>>        "isInIterable() returns true if the node represents an object
>> contained in an Iterable, Map or an array, false otherwise."
>>
>> Given that maps are considered already, the method has to be about
>> "things that are iterable" and not java.lang.Iterable (which j.u.Map
>> doesn't extend). So considering arrays there seems consistent.
>>
>> Or do you, Emmanuel, remember a reason for the current specification
>> and it's actually a bug in the TCK?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1] https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/validation/PropertyPathTest.java#L196
>> _______________________________________________
>> 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 mbenson at apache.org  Fri Jun 16 08:06:32 2017
From: mbenson at apache.org (Matt Benson)
Date: Fri, 16 Jun 2017 07:06:32 -0500
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
Message-ID: <CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>

On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi Matt,
>
> Thanks for bringing this up!
>
> I think adding ContainerElementTypeDescriptor#getContainerClass() is
> one thing needed, but it's not enough. Currently we have
> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
> PropertyDescriptor etc. which returns the container element
> descriptors in the order of type arguments. This also doesn't really
> fit for User#getRoles().
>
> So we could make this a Set<ContainerElementTypeDescriptor> instead,
> and then each element from that set exposes containerClass and
> typeArgumentIndex as you suggest.
>
> It's getting a bit tricky though to get the effective set of all
> container element constraints. Eg. say we have:
>
>     public interface IUserBase {
>         Set<@NotBlank String> getRoles();
>     }
>
>     public interface IUser extends IUserBase {
>         Set<@NotEmpty String> getRoles();
>     }
>
>     public class UserImpl implements IUser {
>         Roles getRoles();
>     }
>
> Then when querying
>
>     validator.getConstraintsForClass( IUser.class )
>         .getConstraintsForProperty( "roles" )
>         .getContainerElementTypes();
>
> We'd get a set with these elements:
>
>     - ContainerElementDescriptor(containerClass=IUser.class,
> typeArgumentIndex=0, constraints={(type=NotEmpty,
> defined=DEFINED_LOCALLY), (type=NotBlank,
> defined=DEFINED_IN_HIERARCHY)}
>     - ContainerElementDescriptor(containerClass=User.class,
> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
> DEFINED_LOCALLY)}
>

I was thinking that the containerClass would be Set.class.

> The descriptor for IUser would have to return the inherited @NotBlank
> as per the defined semantics of getConstraintDescriptors(). So one
> would have to examine all ContainerElementDescriptors and just collect
> the ones that are DEFINED_LOCALLY to have the effective set without
> duplicates.
>

I agree that the set of ContainerElementTypeDescriptors needs to be
reduced to unique type parameters, but I'm not sure I'm following your
argument above. My suggestion above (containerClass=Set.class) would
give an easy way to identify what needs to be collapsed where: onto
Set<[0]>. Consider this:

public class Roles<S extends System> implements Set<String> {
  public S getSystem() {
    ...
  }
  ...
}

public class UserImpl implements IUser {
  public Roles<@ValidSystem UserSystem> getRoles() {
    ...
  }
}

Here Roles would implement a custom container type on top of Iterable
via Set, so the method would return separate ContainerTypeElements for
Roles<[0]> and Set<[0]>. Does that make sense?

Matt

> The alternative would be to explicitly redeclare
> getConstraintDescriptors() for ContainerElementDescriptor and say that
> it doesn't expose constraints from the hierarchy. But this would make
> it very difficult for the user to find all those constraints applying
> to a given container element type (esp. as type arguments could switch
> their order in the hierarchy). So that'd not be my preferred route.
>
> WDYT?
>
> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>
> --Gunnar
>
>
> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> The various descriptor types return constraint information from the
>> entire hierarchy by default. However, in thinking about this I quickly
>> encountered a puzzle which I cannot solve using the current version of
>> the specification. Consider:
>>
>> public interface User {
>>   Set<@NotEmpty String> getRoles();
>> }
>>
>> public class Roles implements Set<String> {
>>  ...
>> }
>>
>> public class UserImpl implements User {
>>   @Override
>>   public Roles getRoles();
>> }
>>
>> What should the metadata of UserImpl provide? The Iterable value
>> extractor is applicable to Roles, but because the return value of the
>> getter has been narrowed, there is no type parameter at this point in
>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>> to return a ContainerElementTypeDescriptor with index 0. This example
>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>> probably a question we need to resolve, unless I have missed something
>> that should be obvious. I think this could be solved if the CETD were
>> to explicitly specify the type with which its argument index is
>> associated. The alternative would be to require a custom
>> ValueExtractor? This seems cumbersome and unnecessary.
>>
>> Thanks,
>> Matt
>> _______________________________________________
>> 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 Jun 16 14:38:03 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 16 Jun 2017 20:38:03 +0200
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
Message-ID: <CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>

2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi Matt,
>>
>> Thanks for bringing this up!
>>
>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>> one thing needed, but it's not enough. Currently we have
>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>> PropertyDescriptor etc. which returns the container element
>> descriptors in the order of type arguments. This also doesn't really
>> fit for User#getRoles().
>>
>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>> and then each element from that set exposes containerClass and
>> typeArgumentIndex as you suggest.
>>
>> It's getting a bit tricky though to get the effective set of all
>> container element constraints. Eg. say we have:
>>
>>     public interface IUserBase {
>>         Set<@NotBlank String> getRoles();
>>     }
>>
>>     public interface IUser extends IUserBase {
>>         Set<@NotEmpty String> getRoles();
>>     }
>>
>>     public class UserImpl implements IUser {
>>         Roles getRoles();
>>     }
>>
>> Then when querying
>>
>>     validator.getConstraintsForClass( IUser.class )
>>         .getConstraintsForProperty( "roles" )
>>         .getContainerElementTypes();
>>
>> We'd get a set with these elements:
>>
>>     - ContainerElementDescriptor(containerClass=IUser.class,
>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>> defined=DEFINED_LOCALLY), (type=NotBlank,
>> defined=DEFINED_IN_HIERARCHY)}
>>     - ContainerElementDescriptor(containerClass=User.class,
>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>> DEFINED_LOCALLY)}
>>
>
> I was thinking that the containerClass would be Set.class.

Yes, you are right of course.

>
>> The descriptor for IUser would have to return the inherited @NotBlank
>> as per the defined semantics of getConstraintDescriptors(). So one
>> would have to examine all ContainerElementDescriptors and just collect
>> the ones that are DEFINED_LOCALLY to have the effective set without
>> duplicates.
>>
>
> I agree that the set of ContainerElementTypeDescriptors needs to be
> reduced to unique type parameters, but I'm not sure I'm following your
> argument above. My suggestion above (containerClass=Set.class) would
> give an easy way to identify what needs to be collapsed where: onto
> Set<[0]>. Consider this:
>
> public class Roles<S extends System> implements Set<String> {
>   public S getSystem() {
>     ...
>   }
>   ...
> }
>
> public class UserImpl implements IUser {
>   public Roles<@ValidSystem UserSystem> getRoles() {
>     ...
>   }
> }
>
> Here Roles would implement a custom container type on top of Iterable
> via Set, so the method would return separate ContainerTypeElements for
> Roles<[0]> and Set<[0]>. Does that make sense?

Yes, it does.

And in my previous example we'd have getContainerElementTypes() return
a set with one descriptor:

ContainerElementDescriptor(containerClass=Set.class,
typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}

(both constraints are defined in the hierarchy from the perspective of UserImpl)

>
> Matt
>
>> The alternative would be to explicitly redeclare
>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>> it doesn't expose constraints from the hierarchy. But this would make
>> it very difficult for the user to find all those constraints applying
>> to a given container element type (esp. as type arguments could switch
>> their order in the hierarchy). So that'd not be my preferred route.
>>
>> WDYT?
>>
>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>
>> --Gunnar
>>
>>
>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> The various descriptor types return constraint information from the
>>> entire hierarchy by default. However, in thinking about this I quickly
>>> encountered a puzzle which I cannot solve using the current version of
>>> the specification. Consider:
>>>
>>> public interface User {
>>>   Set<@NotEmpty String> getRoles();
>>> }
>>>
>>> public class Roles implements Set<String> {
>>>  ...
>>> }
>>>
>>> public class UserImpl implements User {
>>>   @Override
>>>   public Roles getRoles();
>>> }
>>>
>>> What should the metadata of UserImpl provide? The Iterable value
>>> extractor is applicable to Roles, but because the return value of the
>>> getter has been narrowed, there is no type parameter at this point in
>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>> probably a question we need to resolve, unless I have missed something
>>> that should be obvious. I think this could be solved if the CETD were
>>> to explicitly specify the type with which its argument index is
>>> associated. The alternative would be to require a custom
>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>
>>> Thanks,
>>> Matt
>>> _______________________________________________
>>> 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 Jun 16 15:29:55 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 16 Jun 2017 21:29:55 +0200
Subject: [bv-dev] Spec question on constructors
In-Reply-To: <CAE9L6G3ZEkxLz_j1ZvAJgumcg68BNT_Rrr-X=dVRfsQfQqfDXA@mail.gmail.com>
References: <CAE9L6G3ZEkxLz_j1ZvAJgumcg68BNT_Rrr-X=dVRfsQfQqfDXA@mail.gmail.com>
Message-ID: <CADGJaX_Pio1V=UseW_aLsd92TVHziBhS=mUAcNtrmMPXOy+__A@mail.gmail.com>

Hi Matt,

I agree that this sentence shouldn't be there in the JavaDoc; I reckon
it's a copy & paste mistake from getConstraintsForMethod().

Indeed the RI doesn't return a descriptor for a super-type
constructor. Do you know whether it's the same for Apache BVal? If so
I think we should remove the sentence from the JavaDoc. I don't see it
as a migration concern if no certified impl ever implemented that
behaviour.

--Gunnar


2017-06-15 17:15 GMT+02:00 Matt Benson <mbenson at apache.org>:
> The last paragraph of section 5.6.5 states that inheritance rules do
> not apply to constructors as these are not inherited. However, the
> Javadoc of BeanDescriptor#getConstraintsForConstructor(Class<?>...)
> says "Constructor of super types are considered." While it could be
> possible to implement this, what would be the point? These notions
> feel at odds with one another.
>
> Thanks,
> Matt
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Fri Jun 16 16:11:42 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 16 Jun 2017 22:11:42 +0200
Subject: [bv-dev] Towards Proposed Final Draft and Final Approval Ballot
In-Reply-To: <81D0FBB2-AF97-4FD9-A49C-250A0466E0B1@hibernate.org>
References: <CADGJaX-X5LwBjOS2FTbneGCjMh4Jwz2fC-OdVNu9NrTAeMifCA@mail.gmail.com>
	<81D0FBB2-AF97-4FD9-A49C-250A0466E0B1@hibernate.org>
Message-ID: <CADGJaX-ButwhnjRE4N3b+6eRWV=92z+Sark0EtiRx+U32WV0eg@mail.gmail.com>

The diff has been updated as per the changes from today.

One section of specific interest btw. is value extractor resolution:

    http://beanvalidation.org/latest-draft/diff-to-1.1/#constraintdeclarationvalidationprocess-validationroutine-valueextractorresolution

So if you only have time to read a subset of all the changes, this
would be a good place to start.

--Gunnar



2017-06-16 9:08 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> Please EG members, this is the time before it?s too late!
>
> Emmanuel
>
> On 15 Jun 2017, at 20:26, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
> Also, if you haven't done so yet, it'd be a great thing if you could
> spend some time and check out the diff with all the changes since Bean
> Validation 1.1:
>
>    http://beanvalidation.org/latest-draft/diff-to-1.1/
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From mbenson at apache.org  Fri Jun 16 16:19:15 2017
From: mbenson at apache.org (Matt Benson)
Date: Fri, 16 Jun 2017 15:19:15 -0500
Subject: [bv-dev] Spec question on constructors
In-Reply-To: <CADGJaX_Pio1V=UseW_aLsd92TVHziBhS=mUAcNtrmMPXOy+__A@mail.gmail.com>
References: <CAE9L6G3ZEkxLz_j1ZvAJgumcg68BNT_Rrr-X=dVRfsQfQqfDXA@mail.gmail.com>
	<CADGJaX_Pio1V=UseW_aLsd92TVHziBhS=mUAcNtrmMPXOy+__A@mail.gmail.com>
Message-ID: <CAE9L6G0BHMyCMPNWO0oZ+m9X8SxiGSXCfyXviRV8DaCCgsiogw@mail.gmail.com>

Hi Gunnar,
  I don't see that Apache BVal has done this either, but TBH our
metadata is somewhat a mess by this time and I hope to rewrite it for
v2.0.

Matt

On Fri, Jun 16, 2017 at 2:29 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi Matt,
>
> I agree that this sentence shouldn't be there in the JavaDoc; I reckon
> it's a copy & paste mistake from getConstraintsForMethod().
>
> Indeed the RI doesn't return a descriptor for a super-type
> constructor. Do you know whether it's the same for Apache BVal? If so
> I think we should remove the sentence from the JavaDoc. I don't see it
> as a migration concern if no certified impl ever implemented that
> behaviour.
>
> --Gunnar
>
>
> 2017-06-15 17:15 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> The last paragraph of section 5.6.5 states that inheritance rules do
>> not apply to constructors as these are not inherited. However, the
>> Javadoc of BeanDescriptor#getConstraintsForConstructor(Class<?>...)
>> says "Constructor of super types are considered." While it could be
>> possible to implement this, what would be the point? These notions
>> feel at odds with one another.
>>
>> Thanks,
>> Matt
>> _______________________________________________
>> 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 mbenson at apache.org  Sun Jun 18 11:34:31 2017
From: mbenson at apache.org (Matt Benson)
Date: Sun, 18 Jun 2017 10:34:31 -0500
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
Message-ID: <CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>

More thoughts in this vein:

At first I thought that method overrides were the only place you might
have > 1 container class represented, but why wouldn't we support
e.g.:

class Roles implements Set<@NotEmpty String> {
...
}

? Then it'd be possible to extract container elements even at the bean level.

Next, consider parameters. the spec currently says that wildcards
aren't supported, but what about:

<X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);

In this way a parameter could expose multiple container types (pretend
I used unrelated interfaces if that helps). We could save generic
extends support for a future iteration of the spec, but semantically
it makes sense to me so I'd expect we'll eventually have to do it in
any case. I suppose you could even do fields if you annotated some
type parameter of the bean.

I also suspect that it will make sense to introduce a <container>
element to the XML mapping schema with an optional type, to
(optionally?) house the <container-element-type> elements.

Matt


On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> Hi Matt,
>>>
>>> Thanks for bringing this up!
>>>
>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>> one thing needed, but it's not enough. Currently we have
>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>> PropertyDescriptor etc. which returns the container element
>>> descriptors in the order of type arguments. This also doesn't really
>>> fit for User#getRoles().
>>>
>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>> and then each element from that set exposes containerClass and
>>> typeArgumentIndex as you suggest.
>>>
>>> It's getting a bit tricky though to get the effective set of all
>>> container element constraints. Eg. say we have:
>>>
>>>     public interface IUserBase {
>>>         Set<@NotBlank String> getRoles();
>>>     }
>>>
>>>     public interface IUser extends IUserBase {
>>>         Set<@NotEmpty String> getRoles();
>>>     }
>>>
>>>     public class UserImpl implements IUser {
>>>         Roles getRoles();
>>>     }
>>>
>>> Then when querying
>>>
>>>     validator.getConstraintsForClass( IUser.class )
>>>         .getConstraintsForProperty( "roles" )
>>>         .getContainerElementTypes();
>>>
>>> We'd get a set with these elements:
>>>
>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>> defined=DEFINED_IN_HIERARCHY)}
>>>     - ContainerElementDescriptor(containerClass=User.class,
>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>> DEFINED_LOCALLY)}
>>>
>>
>> I was thinking that the containerClass would be Set.class.
>
> Yes, you are right of course.
>
>>
>>> The descriptor for IUser would have to return the inherited @NotBlank
>>> as per the defined semantics of getConstraintDescriptors(). So one
>>> would have to examine all ContainerElementDescriptors and just collect
>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>> duplicates.
>>>
>>
>> I agree that the set of ContainerElementTypeDescriptors needs to be
>> reduced to unique type parameters, but I'm not sure I'm following your
>> argument above. My suggestion above (containerClass=Set.class) would
>> give an easy way to identify what needs to be collapsed where: onto
>> Set<[0]>. Consider this:
>>
>> public class Roles<S extends System> implements Set<String> {
>>   public S getSystem() {
>>     ...
>>   }
>>   ...
>> }
>>
>> public class UserImpl implements IUser {
>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>     ...
>>   }
>> }
>>
>> Here Roles would implement a custom container type on top of Iterable
>> via Set, so the method would return separate ContainerTypeElements for
>> Roles<[0]> and Set<[0]>. Does that make sense?
>
> Yes, it does.
>
> And in my previous example we'd have getContainerElementTypes() return
> a set with one descriptor:
>
> ContainerElementDescriptor(containerClass=Set.class,
> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>
> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>
>>
>> Matt
>>
>>> The alternative would be to explicitly redeclare
>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>> it doesn't expose constraints from the hierarchy. But this would make
>>> it very difficult for the user to find all those constraints applying
>>> to a given container element type (esp. as type arguments could switch
>>> their order in the hierarchy). So that'd not be my preferred route.
>>>
>>> WDYT?
>>>
>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>
>>> --Gunnar
>>>
>>>
>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>> The various descriptor types return constraint information from the
>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>> encountered a puzzle which I cannot solve using the current version of
>>>> the specification. Consider:
>>>>
>>>> public interface User {
>>>>   Set<@NotEmpty String> getRoles();
>>>> }
>>>>
>>>> public class Roles implements Set<String> {
>>>>  ...
>>>> }
>>>>
>>>> public class UserImpl implements User {
>>>>   @Override
>>>>   public Roles getRoles();
>>>> }
>>>>
>>>> What should the metadata of UserImpl provide? The Iterable value
>>>> extractor is applicable to Roles, but because the return value of the
>>>> getter has been narrowed, there is no type parameter at this point in
>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>> probably a question we need to resolve, unless I have missed something
>>>> that should be obvious. I think this could be solved if the CETD were
>>>> to explicitly specify the type with which its argument index is
>>>> associated. The alternative would be to require a custom
>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>
>>>> Thanks,
>>>> Matt
>>>> _______________________________________________
>>>> 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 emmanuel at hibernate.org  Mon Jun 19 08:58:59 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 19 Jun 2017 14:58:59 +0200
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <CADGJaX_1aPVi1mbgbkkH81T6OGwPzHeNGUtrXJxpM0D71dtUjw@mail.gmail.com>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
	<2897EFD5-EABA-44FB-8637-6861426B0D86@hibernate.org>
	<CADGJaX_1aPVi1mbgbkkH81T6OGwPzHeNGUtrXJxpM0D71dtUjw@mail.gmail.com>
Message-ID: <873F3C81-5279-4471-A863-F842A7EEBC66@hibernate.org>


> On 16 Jun 2017, at 12:48, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
>> 
>> 
>> Back to the core subject, I can?t quite remember why I added Map to the list of isIterable() elements.
>> I suppose that if we follow that path, any container that returns multiple elements should return isIterable == true (i.e. containers that call iterableValue, indexedValue or keyedValue.
>> So I?d add arrays and any multi-valued container to the definition of isIterable()
> 
> Ok, cool. I'll add arrays then.
> 
> For other containers, I'd add this when adding more built-in
> containers to the spec in the future.
> 
> 

My point is that isIterable goes beyond the built-in containers. It?s is true of custom containers (e.g. Guava?s etc). If we don?t change the JavaDoc, this is misleading.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170619/f198e80e/attachment.html 

From gunnar at hibernate.org  Mon Jun 19 09:04:38 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 19 Jun 2017 15:04:38 +0200
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
Message-ID: <CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>

Hi,

Putting constraints to type parameters of generic types or methods as
well as putting constraints to type arguments in extends/implements
clauses isn't supported as of BV 2.0. I thought that's mentioned
somewhere in the spec, but couldn't find it during a quick check. If
it's indeed missing, I'll add it. We can look into this for 2.1 of
course.

> I also suspect that it will make sense to introduce a <container>
> element to the XML mapping schema with an optional type, to
> (optionally?) house the <container-element-type> elements.

Could you elaborate on that point a bit? What exactly is the use case for this?

--Gunnar



2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
> More thoughts in this vein:
>
> At first I thought that method overrides were the only place you might
> have > 1 container class represented, but why wouldn't we support
> e.g.:
>
> class Roles implements Set<@NotEmpty String> {
> ...
> }
>
> ? Then it'd be possible to extract container elements even at the bean level.
>
> Next, consider parameters. the spec currently says that wildcards
> aren't supported, but what about:
>
> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);
>
> In this way a parameter could expose multiple container types (pretend
> I used unrelated interfaces if that helps). We could save generic
> extends support for a future iteration of the spec, but semantically
> it makes sense to me so I'd expect we'll eventually have to do it in
> any case. I suppose you could even do fields if you annotated some
> type parameter of the bean.
>
> I also suspect that it will make sense to introduce a <container>
> element to the XML mapping schema with an optional type, to
> (optionally?) house the <container-element-type> elements.
>
> Matt
>
>
> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> Hi Matt,
>>>>
>>>> Thanks for bringing this up!
>>>>
>>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>>> one thing needed, but it's not enough. Currently we have
>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>> PropertyDescriptor etc. which returns the container element
>>>> descriptors in the order of type arguments. This also doesn't really
>>>> fit for User#getRoles().
>>>>
>>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>>> and then each element from that set exposes containerClass and
>>>> typeArgumentIndex as you suggest.
>>>>
>>>> It's getting a bit tricky though to get the effective set of all
>>>> container element constraints. Eg. say we have:
>>>>
>>>>     public interface IUserBase {
>>>>         Set<@NotBlank String> getRoles();
>>>>     }
>>>>
>>>>     public interface IUser extends IUserBase {
>>>>         Set<@NotEmpty String> getRoles();
>>>>     }
>>>>
>>>>     public class UserImpl implements IUser {
>>>>         Roles getRoles();
>>>>     }
>>>>
>>>> Then when querying
>>>>
>>>>     validator.getConstraintsForClass( IUser.class )
>>>>         .getConstraintsForProperty( "roles" )
>>>>         .getContainerElementTypes();
>>>>
>>>> We'd get a set with these elements:
>>>>
>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>> DEFINED_LOCALLY)}
>>>>
>>>
>>> I was thinking that the containerClass would be Set.class.
>>
>> Yes, you are right of course.
>>
>>>
>>>> The descriptor for IUser would have to return the inherited @NotBlank
>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>> would have to examine all ContainerElementDescriptors and just collect
>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>> duplicates.
>>>>
>>>
>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>> reduced to unique type parameters, but I'm not sure I'm following your
>>> argument above. My suggestion above (containerClass=Set.class) would
>>> give an easy way to identify what needs to be collapsed where: onto
>>> Set<[0]>. Consider this:
>>>
>>> public class Roles<S extends System> implements Set<String> {
>>>   public S getSystem() {
>>>     ...
>>>   }
>>>   ...
>>> }
>>>
>>> public class UserImpl implements IUser {
>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>     ...
>>>   }
>>> }
>>>
>>> Here Roles would implement a custom container type on top of Iterable
>>> via Set, so the method would return separate ContainerTypeElements for
>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>
>> Yes, it does.
>>
>> And in my previous example we'd have getContainerElementTypes() return
>> a set with one descriptor:
>>
>> ContainerElementDescriptor(containerClass=Set.class,
>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>
>> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>>
>>>
>>> Matt
>>>
>>>> The alternative would be to explicitly redeclare
>>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>>> it doesn't expose constraints from the hierarchy. But this would make
>>>> it very difficult for the user to find all those constraints applying
>>>> to a given container element type (esp. as type arguments could switch
>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>
>>>> WDYT?
>>>>
>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> The various descriptor types return constraint information from the
>>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>>> encountered a puzzle which I cannot solve using the current version of
>>>>> the specification. Consider:
>>>>>
>>>>> public interface User {
>>>>>   Set<@NotEmpty String> getRoles();
>>>>> }
>>>>>
>>>>> public class Roles implements Set<String> {
>>>>>  ...
>>>>> }
>>>>>
>>>>> public class UserImpl implements User {
>>>>>   @Override
>>>>>   public Roles getRoles();
>>>>> }
>>>>>
>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>> extractor is applicable to Roles, but because the return value of the
>>>>> getter has been narrowed, there is no type parameter at this point in
>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>> probably a question we need to resolve, unless I have missed something
>>>>> that should be obvious. I think this could be solved if the CETD were
>>>>> to explicitly specify the type with which its argument index is
>>>>> associated. The alternative would be to require a custom
>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>> _______________________________________________
>>>>> 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 mbenson at apache.org  Mon Jun 19 11:50:32 2017
From: mbenson at apache.org (Matt Benson)
Date: Mon, 19 Jun 2017 10:50:32 -0500
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
	<CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
Message-ID: <CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>

On Mon, Jun 19, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> Putting constraints to type parameters of generic types or methods as
> well as putting constraints to type arguments in extends/implements
> clauses isn't supported as of BV 2.0. I thought that's mentioned
> somewhere in the spec, but couldn't find it during a quick check. If
> it's indeed missing, I'll add it. We can look into this for 2.1 of
> course.

I'm pretty sure wildcards are explicitly mentioned as not being
supported, and bounds are mentioned there. I don't remember type vars
being included in that. You say "as of BV 2.0." Can I take that to
mean that you think it's at least possible that this might be
something the spec should support in the future? Is this basically a
case of limiting feature creep so that we can finish this iteration
ASAP?

>
>> I also suspect that it will make sense to introduce a <container>
>> element to the XML mapping schema with an optional type, to
>> (optionally?) house the <container-element-type> elements.
>

If we've established that the ContainerElementType needs the container
type to be certain of providing enough information to locate the
relevant value extractor, then consider the XML mapping. Say we have:

interface ILookup {
  Map<String, String> getLookup();
}

class LookupTable extends Hashtable<String, String> {
}

class LookupImpl implements ILookup {
  private LookupTable lookupTable;

  LookupTable getLookup() {
    return lookupTable;
  }
}

And we want to constrain the type parameters of the Map in XML:

<bean class="ILookup">
  <getter name="getLookup">
    <!-- TBD -->
  </getter>
</bean>

We could do:

<container-element-type container-type="java.util.Map" type-argument-index="0">
  <constraint annotation="NotNull" />
  <constraint annotation="NotBlank" />
</container-element-type>
<container-element-type container-type="java.util.Map" type-argument-index="1">
  <constraint annotation="NotBlank" />
</container-element-type>

... and for simplicity's sake, since the typical container likely has
a single element type, we probably should continue to support this.
But should we also allow, e.g.:

<container type="java.util.Map">
  <container-element-type type-argument-index="0">
    <constraint annotation="NotNull" />
    <constraint annotation="NotBlank" />
  </container-element-type>
  <container-element-type type-argument-index="1">
    <constraint annotation="NotBlank" />
  </container-element-type>
</container-type>

WRT the optionality of the type argument index, it's clear that for
containers with a single element type, that could be omitted. Is it
further intended that where the list of container-element-type
elements has a length matching the number of type variables declared
on the container type, these should be understood to specify a 1:1
ordered correspondence? If so, is there a place (and hopefully a more
intelligible way ;) ) to clarify that in the spec?

Matt

> Could you elaborate on that point a bit? What exactly is the use case for this?
>
> --Gunnar
>
>
>
> 2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> More thoughts in this vein:
>>
>> At first I thought that method overrides were the only place you might
>> have > 1 container class represented, but why wouldn't we support
>> e.g.:
>>
>> class Roles implements Set<@NotEmpty String> {
>> ...
>> }
>>
>> ? Then it'd be possible to extract container elements even at the bean level.
>>
>> Next, consider parameters. the spec currently says that wildcards
>> aren't supported, but what about:
>>
>> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);
>>
>> In this way a parameter could expose multiple container types (pretend
>> I used unrelated interfaces if that helps). We could save generic
>> extends support for a future iteration of the spec, but semantically
>> it makes sense to me so I'd expect we'll eventually have to do it in
>> any case. I suppose you could even do fields if you annotated some
>> type parameter of the bean.
>>
>> I also suspect that it will make sense to introduce a <container>
>> element to the XML mapping schema with an optional type, to
>> (optionally?) house the <container-element-type> elements.
>>
>> Matt
>>
>>
>> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>> Hi Matt,
>>>>>
>>>>> Thanks for bringing this up!
>>>>>
>>>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>>>> one thing needed, but it's not enough. Currently we have
>>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>>> PropertyDescriptor etc. which returns the container element
>>>>> descriptors in the order of type arguments. This also doesn't really
>>>>> fit for User#getRoles().
>>>>>
>>>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>>>> and then each element from that set exposes containerClass and
>>>>> typeArgumentIndex as you suggest.
>>>>>
>>>>> It's getting a bit tricky though to get the effective set of all
>>>>> container element constraints. Eg. say we have:
>>>>>
>>>>>     public interface IUserBase {
>>>>>         Set<@NotBlank String> getRoles();
>>>>>     }
>>>>>
>>>>>     public interface IUser extends IUserBase {
>>>>>         Set<@NotEmpty String> getRoles();
>>>>>     }
>>>>>
>>>>>     public class UserImpl implements IUser {
>>>>>         Roles getRoles();
>>>>>     }
>>>>>
>>>>> Then when querying
>>>>>
>>>>>     validator.getConstraintsForClass( IUser.class )
>>>>>         .getConstraintsForProperty( "roles" )
>>>>>         .getContainerElementTypes();
>>>>>
>>>>> We'd get a set with these elements:
>>>>>
>>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>>> DEFINED_LOCALLY)}
>>>>>
>>>>
>>>> I was thinking that the containerClass would be Set.class.
>>>
>>> Yes, you are right of course.
>>>
>>>>
>>>>> The descriptor for IUser would have to return the inherited @NotBlank
>>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>>> would have to examine all ContainerElementDescriptors and just collect
>>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>>> duplicates.
>>>>>
>>>>
>>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>>> reduced to unique type parameters, but I'm not sure I'm following your
>>>> argument above. My suggestion above (containerClass=Set.class) would
>>>> give an easy way to identify what needs to be collapsed where: onto
>>>> Set<[0]>. Consider this:
>>>>
>>>> public class Roles<S extends System> implements Set<String> {
>>>>   public S getSystem() {
>>>>     ...
>>>>   }
>>>>   ...
>>>> }
>>>>
>>>> public class UserImpl implements IUser {
>>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>>     ...
>>>>   }
>>>> }
>>>>
>>>> Here Roles would implement a custom container type on top of Iterable
>>>> via Set, so the method would return separate ContainerTypeElements for
>>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>>
>>> Yes, it does.
>>>
>>> And in my previous example we'd have getContainerElementTypes() return
>>> a set with one descriptor:
>>>
>>> ContainerElementDescriptor(containerClass=Set.class,
>>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>>
>>> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>>>
>>>>
>>>> Matt
>>>>
>>>>> The alternative would be to explicitly redeclare
>>>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>>>> it doesn't expose constraints from the hierarchy. But this would make
>>>>> it very difficult for the user to find all those constraints applying
>>>>> to a given container element type (esp. as type arguments could switch
>>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>>>
>>>>> --Gunnar
>>>>>
>>>>>
>>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>> The various descriptor types return constraint information from the
>>>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>>>> encountered a puzzle which I cannot solve using the current version of
>>>>>> the specification. Consider:
>>>>>>
>>>>>> public interface User {
>>>>>>   Set<@NotEmpty String> getRoles();
>>>>>> }
>>>>>>
>>>>>> public class Roles implements Set<String> {
>>>>>>  ...
>>>>>> }
>>>>>>
>>>>>> public class UserImpl implements User {
>>>>>>   @Override
>>>>>>   public Roles getRoles();
>>>>>> }
>>>>>>
>>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>>> extractor is applicable to Roles, but because the return value of the
>>>>>> getter has been narrowed, there is no type parameter at this point in
>>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>>> probably a question we need to resolve, unless I have missed something
>>>>>> that should be obvious. I think this could be solved if the CETD were
>>>>>> to explicitly specify the type with which its argument index is
>>>>>> associated. The alternative would be to require a custom
>>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>>
>>>>>> Thanks,
>>>>>> Matt
>>>>>> _______________________________________________
>>>>>> 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

From gunnar at hibernate.org  Tue Jun 20 09:04:47 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 20 Jun 2017 15:04:47 +0200
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
	<CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
	<CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
Message-ID: <CADGJaX_HEmmmD_1-7nZ+ibcFp9vVeRtd3WwrFFw=ny7UFHzHNw@mail.gmail.com>

2017-06-19 17:50 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Mon, Jun 19, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi,
>>
>> Putting constraints to type parameters of generic types or methods as
>> well as putting constraints to type arguments in extends/implements
>> clauses isn't supported as of BV 2.0. I thought that's mentioned
>> somewhere in the spec, but couldn't find it during a quick check. If
>> it's indeed missing, I'll add it. We can look into this for 2.1 of
>> course.
>
> I'm pretty sure wildcards are explicitly mentioned as not being
> supported, and bounds are mentioned there. I don't remember type vars
> being included in that. You say "as of BV 2.0." Can I take that to
> mean that you think it's at least possible that this might be
> something the spec should support in the future? Is this basically a
> case of limiting feature creep so that we can finish this iteration
> ASAP?

Yes, it's definitely something we can consider to support in a future
revision. But for BV 2.0 it's too late to add it, as I'll have to
submit the Proposed Final Draft tomorrow or say latest Thursday. While
we can do some more adjustments until Final Approval Ballot, this may
only be corrections and clarifications of already added stuff at this
point unfortunately.

For sure we should explore this on the implementation level, so we
have some experiences already when starting to work on the next spec
revision.


>
>>
>>> I also suspect that it will make sense to introduce a <container>
>>> element to the XML mapping schema with an optional type, to
>>> (optionally?) house the <container-element-type> elements.
>>
>
> If we've established that the ContainerElementType needs the container
> type to be certain of providing enough information to locate the
> relevant value extractor, then consider the XML mapping. Say we have:
>
> interface ILookup {
>   Map<String, String> getLookup();
> }
>
> class LookupTable extends Hashtable<String, String> {
> }
>
> class LookupImpl implements ILookup {
>   private LookupTable lookupTable;
>
>   LookupTable getLookup() {
>     return lookupTable;
>   }
> }
>
> And we want to constrain the type parameters of the Map in XML:
>
> <bean class="ILookup">
>   <getter name="getLookup">
>     <!-- TBD -->
>   </getter>
> </bean>
>
> We could do:
>
> <container-element-type container-type="java.util.Map" type-argument-index="0">
>   <constraint annotation="NotNull" />
>   <constraint annotation="NotBlank" />
> </container-element-type>
> <container-element-type container-type="java.util.Map" type-argument-index="1">
>   <constraint annotation="NotBlank" />
> </container-element-type>

I don't think there's a need to specify the container type in this
case, as this can be obtained from the configured field, method etc.
So for configuring ILookup#getLookup(), it'd look like this with the
currently proposed schema:

    <bean class="ILookup">
        <getter name="lookup">
            <container-element-type type-argument-index="0">
                <constraint annotation="NotNull" />
                <constraint annotation="NotBlank" />
            </container-element-type>
            <container-element-type type-argument-index="1">
                <constraint annotation="NotBlank" />
            </container-element-type>
        </getter>
    </bean>

I.e. this is about Map<String, String> as that's the type of
ILookup#getLookup().

>
> ... and for simplicity's sake, since the typical container likely has
> a single element type, we probably should continue to support this.
> But should we also allow, e.g.:
>
> <container type="java.util.Map">
>   <container-element-type type-argument-index="0">
>     <constraint annotation="NotNull" />
>     <constraint annotation="NotBlank" />
>   </container-element-type>
>   <container-element-type type-argument-index="1">
>     <constraint annotation="NotBlank" />
>   </container-element-type>
> </container-type>

I think it's answered by my previous comment?

>
> WRT the optionality of the type argument index, it's clear that for
> containers with a single element type, that could be omitted. Is it
> further intended that where the list of container-element-type
> elements has a length matching the number of type variables declared
> on the container type, these should be understood to specify a 1:1
> ordered correspondence? If so, is there a place (and hopefully a more
> intelligible way ;) ) to clarify that in the spec?

That behaviour is not intended. I don't like the idea of relying on
ordering, as it'd require you to specify (empty) container element
type nodes for all type arguments, also if only one is to be
constrained.

That's what we currently say in the spec:

    "The type-argument-index is used to specify the index of the
configured type argument. The type-argument-index can be omitted, if
the container element type has exactly one type argument. [...] If an
invalid container type element configuration is detected, a
ValidationException is raised. This includes the following
configuration errors:

    * The type of the surrounding element (field, getter etc.) has no
type arguments.
    * The type of the surrounding element has no type argument with
the index given via type-argument-index.
    * The type of the surrounding element has multiple type arguments
and no index is given via type-argument-index.
    * The same type argument of the surrounding element is configured
multiple times."

Do you think this is clear enough or should we change the wording in some way?


>
> Matt
>
>> Could you elaborate on that point a bit? What exactly is the use case for this?
>>
>> --Gunnar
>>
>>
>>
>> 2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> More thoughts in this vein:
>>>
>>> At first I thought that method overrides were the only place you might
>>> have > 1 container class represented, but why wouldn't we support
>>> e.g.:
>>>
>>> class Roles implements Set<@NotEmpty String> {
>>> ...
>>> }
>>>
>>> ? Then it'd be possible to extract container elements even at the bean level.
>>>
>>> Next, consider parameters. the spec currently says that wildcards
>>> aren't supported, but what about:
>>>
>>> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);
>>>
>>> In this way a parameter could expose multiple container types (pretend
>>> I used unrelated interfaces if that helps). We could save generic
>>> extends support for a future iteration of the spec, but semantically
>>> it makes sense to me so I'd expect we'll eventually have to do it in
>>> any case. I suppose you could even do fields if you annotated some
>>> type parameter of the bean.
>>>
>>> I also suspect that it will make sense to introduce a <container>
>>> element to the XML mapping schema with an optional type, to
>>> (optionally?) house the <container-element-type> elements.
>>>
>>> Matt
>>>
>>>
>>> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>> Hi Matt,
>>>>>>
>>>>>> Thanks for bringing this up!
>>>>>>
>>>>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>>>>> one thing needed, but it's not enough. Currently we have
>>>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>>>> PropertyDescriptor etc. which returns the container element
>>>>>> descriptors in the order of type arguments. This also doesn't really
>>>>>> fit for User#getRoles().
>>>>>>
>>>>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>>>>> and then each element from that set exposes containerClass and
>>>>>> typeArgumentIndex as you suggest.
>>>>>>
>>>>>> It's getting a bit tricky though to get the effective set of all
>>>>>> container element constraints. Eg. say we have:
>>>>>>
>>>>>>     public interface IUserBase {
>>>>>>         Set<@NotBlank String> getRoles();
>>>>>>     }
>>>>>>
>>>>>>     public interface IUser extends IUserBase {
>>>>>>         Set<@NotEmpty String> getRoles();
>>>>>>     }
>>>>>>
>>>>>>     public class UserImpl implements IUser {
>>>>>>         Roles getRoles();
>>>>>>     }
>>>>>>
>>>>>> Then when querying
>>>>>>
>>>>>>     validator.getConstraintsForClass( IUser.class )
>>>>>>         .getConstraintsForProperty( "roles" )
>>>>>>         .getContainerElementTypes();
>>>>>>
>>>>>> We'd get a set with these elements:
>>>>>>
>>>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>>>> DEFINED_LOCALLY)}
>>>>>>
>>>>>
>>>>> I was thinking that the containerClass would be Set.class.
>>>>
>>>> Yes, you are right of course.
>>>>
>>>>>
>>>>>> The descriptor for IUser would have to return the inherited @NotBlank
>>>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>>>> would have to examine all ContainerElementDescriptors and just collect
>>>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>>>> duplicates.
>>>>>>
>>>>>
>>>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>>>> reduced to unique type parameters, but I'm not sure I'm following your
>>>>> argument above. My suggestion above (containerClass=Set.class) would
>>>>> give an easy way to identify what needs to be collapsed where: onto
>>>>> Set<[0]>. Consider this:
>>>>>
>>>>> public class Roles<S extends System> implements Set<String> {
>>>>>   public S getSystem() {
>>>>>     ...
>>>>>   }
>>>>>   ...
>>>>> }
>>>>>
>>>>> public class UserImpl implements IUser {
>>>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>>>     ...
>>>>>   }
>>>>> }
>>>>>
>>>>> Here Roles would implement a custom container type on top of Iterable
>>>>> via Set, so the method would return separate ContainerTypeElements for
>>>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>>>
>>>> Yes, it does.
>>>>
>>>> And in my previous example we'd have getContainerElementTypes() return
>>>> a set with one descriptor:
>>>>
>>>> ContainerElementDescriptor(containerClass=Set.class,
>>>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>>>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>>>
>>>> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>>>>
>>>>>
>>>>> Matt
>>>>>
>>>>>> The alternative would be to explicitly redeclare
>>>>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>>>>> it doesn't expose constraints from the hierarchy. But this would make
>>>>>> it very difficult for the user to find all those constraints applying
>>>>>> to a given container element type (esp. as type arguments could switch
>>>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>>>>
>>>>>> --Gunnar
>>>>>>
>>>>>>
>>>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>> The various descriptor types return constraint information from the
>>>>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>>>>> encountered a puzzle which I cannot solve using the current version of
>>>>>>> the specification. Consider:
>>>>>>>
>>>>>>> public interface User {
>>>>>>>   Set<@NotEmpty String> getRoles();
>>>>>>> }
>>>>>>>
>>>>>>> public class Roles implements Set<String> {
>>>>>>>  ...
>>>>>>> }
>>>>>>>
>>>>>>> public class UserImpl implements User {
>>>>>>>   @Override
>>>>>>>   public Roles getRoles();
>>>>>>> }
>>>>>>>
>>>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>>>> extractor is applicable to Roles, but because the return value of the
>>>>>>> getter has been narrowed, there is no type parameter at this point in
>>>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>>>> probably a question we need to resolve, unless I have missed something
>>>>>>> that should be obvious. I think this could be solved if the CETD were
>>>>>>> to explicitly specify the type with which its argument index is
>>>>>>> associated. The alternative would be to require a custom
>>>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matt
>>>>>>> _______________________________________________
>>>>>>> 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
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Tue Jun 20 11:58:23 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 20 Jun 2017 17:58:23 +0200
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <873F3C81-5279-4471-A863-F842A7EEBC66@hibernate.org>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
	<2897EFD5-EABA-44FB-8637-6861426B0D86@hibernate.org>
	<CADGJaX_1aPVi1mbgbkkH81T6OGwPzHeNGUtrXJxpM0D71dtUjw@mail.gmail.com>
	<873F3C81-5279-4471-A863-F842A7EEBC66@hibernate.org>
Message-ID: <CADGJaX8b88yVwVySu43SxZ4kFj+C8L+798G9sA14kmZ=UdiE3Q@mail.gmail.com>

2017-06-19 14:58 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 16 Jun 2017, at 12:48, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
>
> Back to the core subject, I can?t quite remember why I added Map to the list
> of isIterable() elements.
> I suppose that if we follow that path, any container that returns multiple
> elements should return isIterable == true (i.e. containers that call
> iterableValue, indexedValue or keyedValue.
> So I?d add arrays and any multi-valued container to the definition of
> isIterable()
>
>
> Ok, cool. I'll add arrays then.
>
> For other containers, I'd add this when adding more built-in
> containers to the spec in the future.
>
>
>
> My point is that isIterable goes beyond the built-in containers. It?s is
> true of custom containers (e.g. Guava?s etc). If we don?t change the
> JavaDoc, this is misleading.

Ok, it seems we need to mention the notion of custom supported
containers then. How about

    @return {@code true} if the node represents an object contained in
a multi-valued container such as {@code Iterable} or {@code Map} or an
array, {@code false} otherwise


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


From emmanuel at hibernate.org  Tue Jun 20 12:46:15 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 20 Jun 2017 18:46:15 +0200
Subject: [bv-dev] Node#isInIterable() for arrays
In-Reply-To: <CADGJaX8b88yVwVySu43SxZ4kFj+C8L+798G9sA14kmZ=UdiE3Q@mail.gmail.com>
References: <CADGJaX9Nnz=kNiy+fRQBq6sTm5a0LBJpy38KXfGMWgQ9zd_X+g@mail.gmail.com>
	<2897EFD5-EABA-44FB-8637-6861426B0D86@hibernate.org>
	<CADGJaX_1aPVi1mbgbkkH81T6OGwPzHeNGUtrXJxpM0D71dtUjw@mail.gmail.com>
	<873F3C81-5279-4471-A863-F842A7EEBC66@hibernate.org>
	<CADGJaX8b88yVwVySu43SxZ4kFj+C8L+798G9sA14kmZ=UdiE3Q@mail.gmail.com>
Message-ID: <B9BE7291-9224-40AE-B22C-1E12CBCBDBC6@hibernate.org>

OK
I?d prefer e.g. to such as which feels all encompassing but that?s being picky.

> On 20 Jun 2017, at 17:58, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> 2017-06-19 14:58 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> 
>> On 16 Jun 2017, at 12:48, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 
>> 
>> 
>> Back to the core subject, I can?t quite remember why I added Map to the list
>> of isIterable() elements.
>> I suppose that if we follow that path, any container that returns multiple
>> elements should return isIterable == true (i.e. containers that call
>> iterableValue, indexedValue or keyedValue.
>> So I?d add arrays and any multi-valued container to the definition of
>> isIterable()
>> 
>> 
>> Ok, cool. I'll add arrays then.
>> 
>> For other containers, I'd add this when adding more built-in
>> containers to the spec in the future.
>> 
>> 
>> 
>> My point is that isIterable goes beyond the built-in containers. It?s is
>> true of custom containers (e.g. Guava?s etc). If we don?t change the
>> JavaDoc, this is misleading.
> 
> Ok, it seems we need to mention the notion of custom supported
> containers then. How about
> 
>    @return {@code true} if the node represents an object contained in
> a multi-valued container such as {@code Iterable} or {@code Map} or an
> array, {@code false} otherwise
> 
> 
>> 
>> _______________________________________________
>> 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 emmanuel at hibernate.org  Tue Jun 20 12:53:22 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 20 Jun 2017 18:53:22 +0200
Subject: [bv-dev] support for non-standard Java beans
In-Reply-To: <CACjfWpcYn6imYK1FsWt+JTNy2FByF4asp3oKqGKherrArpyf9Q@mail.gmail.com>
References: <CACjfWpcYn6imYK1FsWt+JTNy2FByF4asp3oKqGKherrArpyf9Q@mail.gmail.com>
Message-ID: <49C062F5-9CFF-4392-BF3B-31A1CB5C12D8@hibernate.org>

The main problem is to differentiate a method from a getter in such universe where you throw the convention out the window.

> On 14 Jun 2017, at 06:12, Andrei Sereda <andrei at sereda.cc> wrote:
> 
> Hello,
> 
> Apologies  if I hijack this mailing list. Please redirect me to right DL / forum, if it is the case.
> 
> I would like to inquire if custom method resolution is within the scope of the spec (or exists already) for beans which don't exactly follow JavaBean convention. By custom, I mean name() vs getName(). 
> 
> I've noticed, lately, the trend to use code generators (Immutables <https://immutables.github.io/>, FreeBuilder <http://freebuilder.inferred.org/>, AutoValue <https://github.com/google/auto/blob/master/value/userguide/index.md> etc.) for domain entities. By default they all use name() for getters (instead of getName()) :
> 
> @FreeBuilder
> public interface Person {
> 
>   @NotBlank
>   String name();
>  
>   @Min(16) 
>   int age();
> 
>   ....
> }
> 
> It would be nice if BeanValidation could support such use-case via pluggable (getter / setter) method resolver (for example).
> 
> Associated JIRA  ticket HV-1363 <https://hibernate.atlassian.net/browse/HV-1363>
> 
> Thanks in advance,
> Andrei.
> _______________________________________________
> 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/20170620/eaa5589a/attachment-0001.html 

From gunnar at hibernate.org  Tue Jun 20 16:06:11 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 20 Jun 2017 22:06:11 +0200
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CADGJaX_HEmmmD_1-7nZ+ibcFp9vVeRtd3WwrFFw=ny7UFHzHNw@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
	<CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
	<CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
	<CADGJaX_HEmmmD_1-7nZ+ibcFp9vVeRtd3WwrFFw=ny7UFHzHNw@mail.gmail.com>
Message-ID: <CADGJaX9up8m0CHMT6G8aCA_CT-=BB0xxemmCK==5eDWHgVL3xg@mail.gmail.com>

Matt,

I've prepared a PR with the discussed change to the metadata API:
https://github.com/beanvalidation/beanvalidation-spec/pull/209

Could you take a look and let me know whether it satisfies the
requirements as you see them? It has been a long day here and I'll
think about it again tomorrow with a fresh mind; any feedback you may
have is very welcome.

Thanks!

2017-06-20 15:04 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> 2017-06-19 17:50 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> On Mon, Jun 19, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> Hi,
>>>
>>> Putting constraints to type parameters of generic types or methods as
>>> well as putting constraints to type arguments in extends/implements
>>> clauses isn't supported as of BV 2.0. I thought that's mentioned
>>> somewhere in the spec, but couldn't find it during a quick check. If
>>> it's indeed missing, I'll add it. We can look into this for 2.1 of
>>> course.
>>
>> I'm pretty sure wildcards are explicitly mentioned as not being
>> supported, and bounds are mentioned there. I don't remember type vars
>> being included in that. You say "as of BV 2.0." Can I take that to
>> mean that you think it's at least possible that this might be
>> something the spec should support in the future? Is this basically a
>> case of limiting feature creep so that we can finish this iteration
>> ASAP?
>
> Yes, it's definitely something we can consider to support in a future
> revision. But for BV 2.0 it's too late to add it, as I'll have to
> submit the Proposed Final Draft tomorrow or say latest Thursday. While
> we can do some more adjustments until Final Approval Ballot, this may
> only be corrections and clarifications of already added stuff at this
> point unfortunately.
>
> For sure we should explore this on the implementation level, so we
> have some experiences already when starting to work on the next spec
> revision.
>
>
>>
>>>
>>>> I also suspect that it will make sense to introduce a <container>
>>>> element to the XML mapping schema with an optional type, to
>>>> (optionally?) house the <container-element-type> elements.
>>>
>>
>> If we've established that the ContainerElementType needs the container
>> type to be certain of providing enough information to locate the
>> relevant value extractor, then consider the XML mapping. Say we have:
>>
>> interface ILookup {
>>   Map<String, String> getLookup();
>> }
>>
>> class LookupTable extends Hashtable<String, String> {
>> }
>>
>> class LookupImpl implements ILookup {
>>   private LookupTable lookupTable;
>>
>>   LookupTable getLookup() {
>>     return lookupTable;
>>   }
>> }
>>
>> And we want to constrain the type parameters of the Map in XML:
>>
>> <bean class="ILookup">
>>   <getter name="getLookup">
>>     <!-- TBD -->
>>   </getter>
>> </bean>
>>
>> We could do:
>>
>> <container-element-type container-type="java.util.Map" type-argument-index="0">
>>   <constraint annotation="NotNull" />
>>   <constraint annotation="NotBlank" />
>> </container-element-type>
>> <container-element-type container-type="java.util.Map" type-argument-index="1">
>>   <constraint annotation="NotBlank" />
>> </container-element-type>
>
> I don't think there's a need to specify the container type in this
> case, as this can be obtained from the configured field, method etc.
> So for configuring ILookup#getLookup(), it'd look like this with the
> currently proposed schema:
>
>     <bean class="ILookup">
>         <getter name="lookup">
>             <container-element-type type-argument-index="0">
>                 <constraint annotation="NotNull" />
>                 <constraint annotation="NotBlank" />
>             </container-element-type>
>             <container-element-type type-argument-index="1">
>                 <constraint annotation="NotBlank" />
>             </container-element-type>
>         </getter>
>     </bean>
>
> I.e. this is about Map<String, String> as that's the type of
> ILookup#getLookup().
>
>>
>> ... and for simplicity's sake, since the typical container likely has
>> a single element type, we probably should continue to support this.
>> But should we also allow, e.g.:
>>
>> <container type="java.util.Map">
>>   <container-element-type type-argument-index="0">
>>     <constraint annotation="NotNull" />
>>     <constraint annotation="NotBlank" />
>>   </container-element-type>
>>   <container-element-type type-argument-index="1">
>>     <constraint annotation="NotBlank" />
>>   </container-element-type>
>> </container-type>
>
> I think it's answered by my previous comment?
>
>>
>> WRT the optionality of the type argument index, it's clear that for
>> containers with a single element type, that could be omitted. Is it
>> further intended that where the list of container-element-type
>> elements has a length matching the number of type variables declared
>> on the container type, these should be understood to specify a 1:1
>> ordered correspondence? If so, is there a place (and hopefully a more
>> intelligible way ;) ) to clarify that in the spec?
>
> That behaviour is not intended. I don't like the idea of relying on
> ordering, as it'd require you to specify (empty) container element
> type nodes for all type arguments, also if only one is to be
> constrained.
>
> That's what we currently say in the spec:
>
>     "The type-argument-index is used to specify the index of the
> configured type argument. The type-argument-index can be omitted, if
> the container element type has exactly one type argument. [...] If an
> invalid container type element configuration is detected, a
> ValidationException is raised. This includes the following
> configuration errors:
>
>     * The type of the surrounding element (field, getter etc.) has no
> type arguments.
>     * The type of the surrounding element has no type argument with
> the index given via type-argument-index.
>     * The type of the surrounding element has multiple type arguments
> and no index is given via type-argument-index.
>     * The same type argument of the surrounding element is configured
> multiple times."
>
> Do you think this is clear enough or should we change the wording in some way?
>
>
>>
>> Matt
>>
>>> Could you elaborate on that point a bit? What exactly is the use case for this?
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> 2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>> More thoughts in this vein:
>>>>
>>>> At first I thought that method overrides were the only place you might
>>>> have > 1 container class represented, but why wouldn't we support
>>>> e.g.:
>>>>
>>>> class Roles implements Set<@NotEmpty String> {
>>>> ...
>>>> }
>>>>
>>>> ? Then it'd be possible to extract container elements even at the bean level.
>>>>
>>>> Next, consider parameters. the spec currently says that wildcards
>>>> aren't supported, but what about:
>>>>
>>>> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);
>>>>
>>>> In this way a parameter could expose multiple container types (pretend
>>>> I used unrelated interfaces if that helps). We could save generic
>>>> extends support for a future iteration of the spec, but semantically
>>>> it makes sense to me so I'd expect we'll eventually have to do it in
>>>> any case. I suppose you could even do fields if you annotated some
>>>> type parameter of the bean.
>>>>
>>>> I also suspect that it will make sense to introduce a <container>
>>>> element to the XML mapping schema with an optional type, to
>>>> (optionally?) house the <container-element-type> elements.
>>>>
>>>> Matt
>>>>
>>>>
>>>> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>>> Hi Matt,
>>>>>>>
>>>>>>> Thanks for bringing this up!
>>>>>>>
>>>>>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>>>>>> one thing needed, but it's not enough. Currently we have
>>>>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>>>>> PropertyDescriptor etc. which returns the container element
>>>>>>> descriptors in the order of type arguments. This also doesn't really
>>>>>>> fit for User#getRoles().
>>>>>>>
>>>>>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>>>>>> and then each element from that set exposes containerClass and
>>>>>>> typeArgumentIndex as you suggest.
>>>>>>>
>>>>>>> It's getting a bit tricky though to get the effective set of all
>>>>>>> container element constraints. Eg. say we have:
>>>>>>>
>>>>>>>     public interface IUserBase {
>>>>>>>         Set<@NotBlank String> getRoles();
>>>>>>>     }
>>>>>>>
>>>>>>>     public interface IUser extends IUserBase {
>>>>>>>         Set<@NotEmpty String> getRoles();
>>>>>>>     }
>>>>>>>
>>>>>>>     public class UserImpl implements IUser {
>>>>>>>         Roles getRoles();
>>>>>>>     }
>>>>>>>
>>>>>>> Then when querying
>>>>>>>
>>>>>>>     validator.getConstraintsForClass( IUser.class )
>>>>>>>         .getConstraintsForProperty( "roles" )
>>>>>>>         .getContainerElementTypes();
>>>>>>>
>>>>>>> We'd get a set with these elements:
>>>>>>>
>>>>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>>>>> DEFINED_LOCALLY)}
>>>>>>>
>>>>>>
>>>>>> I was thinking that the containerClass would be Set.class.
>>>>>
>>>>> Yes, you are right of course.
>>>>>
>>>>>>
>>>>>>> The descriptor for IUser would have to return the inherited @NotBlank
>>>>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>>>>> would have to examine all ContainerElementDescriptors and just collect
>>>>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>>>>> duplicates.
>>>>>>>
>>>>>>
>>>>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>>>>> reduced to unique type parameters, but I'm not sure I'm following your
>>>>>> argument above. My suggestion above (containerClass=Set.class) would
>>>>>> give an easy way to identify what needs to be collapsed where: onto
>>>>>> Set<[0]>. Consider this:
>>>>>>
>>>>>> public class Roles<S extends System> implements Set<String> {
>>>>>>   public S getSystem() {
>>>>>>     ...
>>>>>>   }
>>>>>>   ...
>>>>>> }
>>>>>>
>>>>>> public class UserImpl implements IUser {
>>>>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>>>>     ...
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> Here Roles would implement a custom container type on top of Iterable
>>>>>> via Set, so the method would return separate ContainerTypeElements for
>>>>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>>>>
>>>>> Yes, it does.
>>>>>
>>>>> And in my previous example we'd have getContainerElementTypes() return
>>>>> a set with one descriptor:
>>>>>
>>>>> ContainerElementDescriptor(containerClass=Set.class,
>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>>>>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>>>>
>>>>> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>>>>>
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>> The alternative would be to explicitly redeclare
>>>>>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>>>>>> it doesn't expose constraints from the hierarchy. But this would make
>>>>>>> it very difficult for the user to find all those constraints applying
>>>>>>> to a given container element type (esp. as type arguments could switch
>>>>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>>>>>
>>>>>>> --Gunnar
>>>>>>>
>>>>>>>
>>>>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>>> The various descriptor types return constraint information from the
>>>>>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>>>>>> encountered a puzzle which I cannot solve using the current version of
>>>>>>>> the specification. Consider:
>>>>>>>>
>>>>>>>> public interface User {
>>>>>>>>   Set<@NotEmpty String> getRoles();
>>>>>>>> }
>>>>>>>>
>>>>>>>> public class Roles implements Set<String> {
>>>>>>>>  ...
>>>>>>>> }
>>>>>>>>
>>>>>>>> public class UserImpl implements User {
>>>>>>>>   @Override
>>>>>>>>   public Roles getRoles();
>>>>>>>> }
>>>>>>>>
>>>>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>>>>> extractor is applicable to Roles, but because the return value of the
>>>>>>>> getter has been narrowed, there is no type parameter at this point in
>>>>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>>>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>>>>> probably a question we need to resolve, unless I have missed something
>>>>>>>> that should be obvious. I think this could be solved if the CETD were
>>>>>>>> to explicitly specify the type with which its argument index is
>>>>>>>> associated. The alternative would be to require a custom
>>>>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Matt
>>>>>>>> _______________________________________________
>>>>>>>> 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
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From mbenson at apache.org  Tue Jun 20 16:36:59 2017
From: mbenson at apache.org (Matt Benson)
Date: Tue, 20 Jun 2017 15:36:59 -0500
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CADGJaX_HEmmmD_1-7nZ+ibcFp9vVeRtd3WwrFFw=ny7UFHzHNw@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
	<CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
	<CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
	<CADGJaX_HEmmmD_1-7nZ+ibcFp9vVeRtd3WwrFFw=ny7UFHzHNw@mail.gmail.com>
Message-ID: <CAE9L6G2Py2-4JnPn42K2nb9ToMtFnjcd+vo76bMDv74Xi7QCTQ@mail.gmail.com>

On Tue, Jun 20, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2017-06-19 17:50 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> On Mon, Jun 19, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> Hi,
>>>
>>> Putting constraints to type parameters of generic types or methods as
>>> well as putting constraints to type arguments in extends/implements
>>> clauses isn't supported as of BV 2.0. I thought that's mentioned
>>> somewhere in the spec, but couldn't find it during a quick check. If
>>> it's indeed missing, I'll add it. We can look into this for 2.1 of
>>> course.
>>
>> I'm pretty sure wildcards are explicitly mentioned as not being
>> supported, and bounds are mentioned there. I don't remember type vars
>> being included in that. You say "as of BV 2.0." Can I take that to
>> mean that you think it's at least possible that this might be
>> something the spec should support in the future? Is this basically a
>> case of limiting feature creep so that we can finish this iteration
>> ASAP?
>
> Yes, it's definitely something we can consider to support in a future
> revision. But for BV 2.0 it's too late to add it, as I'll have to
> submit the Proposed Final Draft tomorrow or say latest Thursday. While
> we can do some more adjustments until Final Approval Ballot, this may
> only be corrections and clarifications of already added stuff at this
> point unfortunately.
>
> For sure we should explore this on the implementation level, so we
> have some experiences already when starting to work on the next spec
> revision.
>
>
>>
>>>
>>>> I also suspect that it will make sense to introduce a <container>
>>>> element to the XML mapping schema with an optional type, to
>>>> (optionally?) house the <container-element-type> elements.
>>>
>>
>> If we've established that the ContainerElementType needs the container
>> type to be certain of providing enough information to locate the
>> relevant value extractor, then consider the XML mapping. Say we have:
>>
>> interface ILookup {
>>   Map<String, String> getLookup();
>> }
>>
>> class LookupTable extends Hashtable<String, String> {
>> }
>>
>> class LookupImpl implements ILookup {
>>   private LookupTable lookupTable;
>>
>>   LookupTable getLookup() {
>>     return lookupTable;
>>   }
>> }
>>
>> And we want to constrain the type parameters of the Map in XML:
>>
>> <bean class="ILookup">
>>   <getter name="getLookup">
>>     <!-- TBD -->
>>   </getter>
>> </bean>
>>
>> We could do:
>>
>> <container-element-type container-type="java.util.Map" type-argument-index="0">
>>   <constraint annotation="NotNull" />
>>   <constraint annotation="NotBlank" />
>> </container-element-type>
>> <container-element-type container-type="java.util.Map" type-argument-index="1">
>>   <constraint annotation="NotBlank" />
>> </container-element-type>
>
> I don't think there's a need to specify the container type in this
> case, as this can be obtained from the configured field, method etc.
> So for configuring ILookup#getLookup(), it'd look like this with the
> currently proposed schema:
>
>     <bean class="ILookup">
>         <getter name="lookup">
>             <container-element-type type-argument-index="0">
>                 <constraint annotation="NotNull" />
>                 <constraint annotation="NotBlank" />
>             </container-element-type>
>             <container-element-type type-argument-index="1">
>                 <constraint annotation="NotBlank" />
>             </container-element-type>
>         </getter>
>     </bean>
>
> I.e. this is about Map<String, String> as that's the type of
> ILookup#getLookup().
>
>>
>> ... and for simplicity's sake, since the typical container likely has
>> a single element type, we probably should continue to support this.
>> But should we also allow, e.g.:
>>
>> <container type="java.util.Map">
>>   <container-element-type type-argument-index="0">
>>     <constraint annotation="NotNull" />
>>     <constraint annotation="NotBlank" />
>>   </container-element-type>
>>   <container-element-type type-argument-index="1">
>>     <constraint annotation="NotBlank" />
>>   </container-element-type>
>> </container-type>
>
> I think it's answered by my previous comment?
>

My thinking was to make it possible for a user to configure container
element constraints for various levels of the inheritance hierarchy
for a given e.g. method return type. So continuing the lookup example,
perhaps we want to constrain the key of a LookupTable only for
LookupImpl and not for every implementation of ILookup. Given the time
issue though we can leave this alone for now.

>>
>> WRT the optionality of the type argument index, it's clear that for
>> containers with a single element type, that could be omitted. Is it
>> further intended that where the list of container-element-type
>> elements has a length matching the number of type variables declared
>> on the container type, these should be understood to specify a 1:1
>> ordered correspondence? If so, is there a place (and hopefully a more
>> intelligible way ;) ) to clarify that in the spec?
>
> That behaviour is not intended. I don't like the idea of relying on
> ordering, as it'd require you to specify (empty) container element
> type nodes for all type arguments, also if only one is to be
> constrained.
>
> That's what we currently say in the spec:
>
>     "The type-argument-index is used to specify the index of the
> configured type argument. The type-argument-index can be omitted, if
> the container element type has exactly one type argument. [...] If an
> invalid container type element configuration is detected, a
> ValidationException is raised. This includes the following
> configuration errors:
>
>     * The type of the surrounding element (field, getter etc.) has no
> type arguments.
>     * The type of the surrounding element has no type argument with
> the index given via type-argument-index.
>     * The type of the surrounding element has multiple type arguments
> and no index is given via type-argument-index.
>     * The same type argument of the surrounding element is configured
> multiple times."
>
> Do you think this is clear enough or should we change the wording in some way?
>

Seems okay to me.

Matt

>
>>
>> Matt
>>
>>> Could you elaborate on that point a bit? What exactly is the use case for this?
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> 2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>> More thoughts in this vein:
>>>>
>>>> At first I thought that method overrides were the only place you might
>>>> have > 1 container class represented, but why wouldn't we support
>>>> e.g.:
>>>>
>>>> class Roles implements Set<@NotEmpty String> {
>>>> ...
>>>> }
>>>>
>>>> ? Then it'd be possible to extract container elements even at the bean level.
>>>>
>>>> Next, consider parameters. the spec currently says that wildcards
>>>> aren't supported, but what about:
>>>>
>>>> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);
>>>>
>>>> In this way a parameter could expose multiple container types (pretend
>>>> I used unrelated interfaces if that helps). We could save generic
>>>> extends support for a future iteration of the spec, but semantically
>>>> it makes sense to me so I'd expect we'll eventually have to do it in
>>>> any case. I suppose you could even do fields if you annotated some
>>>> type parameter of the bean.
>>>>
>>>> I also suspect that it will make sense to introduce a <container>
>>>> element to the XML mapping schema with an optional type, to
>>>> (optionally?) house the <container-element-type> elements.
>>>>
>>>> Matt
>>>>
>>>>
>>>> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>>> Hi Matt,
>>>>>>>
>>>>>>> Thanks for bringing this up!
>>>>>>>
>>>>>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>>>>>> one thing needed, but it's not enough. Currently we have
>>>>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>>>>> PropertyDescriptor etc. which returns the container element
>>>>>>> descriptors in the order of type arguments. This also doesn't really
>>>>>>> fit for User#getRoles().
>>>>>>>
>>>>>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>>>>>> and then each element from that set exposes containerClass and
>>>>>>> typeArgumentIndex as you suggest.
>>>>>>>
>>>>>>> It's getting a bit tricky though to get the effective set of all
>>>>>>> container element constraints. Eg. say we have:
>>>>>>>
>>>>>>>     public interface IUserBase {
>>>>>>>         Set<@NotBlank String> getRoles();
>>>>>>>     }
>>>>>>>
>>>>>>>     public interface IUser extends IUserBase {
>>>>>>>         Set<@NotEmpty String> getRoles();
>>>>>>>     }
>>>>>>>
>>>>>>>     public class UserImpl implements IUser {
>>>>>>>         Roles getRoles();
>>>>>>>     }
>>>>>>>
>>>>>>> Then when querying
>>>>>>>
>>>>>>>     validator.getConstraintsForClass( IUser.class )
>>>>>>>         .getConstraintsForProperty( "roles" )
>>>>>>>         .getContainerElementTypes();
>>>>>>>
>>>>>>> We'd get a set with these elements:
>>>>>>>
>>>>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>>>>> DEFINED_LOCALLY)}
>>>>>>>
>>>>>>
>>>>>> I was thinking that the containerClass would be Set.class.
>>>>>
>>>>> Yes, you are right of course.
>>>>>
>>>>>>
>>>>>>> The descriptor for IUser would have to return the inherited @NotBlank
>>>>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>>>>> would have to examine all ContainerElementDescriptors and just collect
>>>>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>>>>> duplicates.
>>>>>>>
>>>>>>
>>>>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>>>>> reduced to unique type parameters, but I'm not sure I'm following your
>>>>>> argument above. My suggestion above (containerClass=Set.class) would
>>>>>> give an easy way to identify what needs to be collapsed where: onto
>>>>>> Set<[0]>. Consider this:
>>>>>>
>>>>>> public class Roles<S extends System> implements Set<String> {
>>>>>>   public S getSystem() {
>>>>>>     ...
>>>>>>   }
>>>>>>   ...
>>>>>> }
>>>>>>
>>>>>> public class UserImpl implements IUser {
>>>>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>>>>     ...
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> Here Roles would implement a custom container type on top of Iterable
>>>>>> via Set, so the method would return separate ContainerTypeElements for
>>>>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>>>>
>>>>> Yes, it does.
>>>>>
>>>>> And in my previous example we'd have getContainerElementTypes() return
>>>>> a set with one descriptor:
>>>>>
>>>>> ContainerElementDescriptor(containerClass=Set.class,
>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>>>>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>>>>
>>>>> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>>>>>
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>> The alternative would be to explicitly redeclare
>>>>>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>>>>>> it doesn't expose constraints from the hierarchy. But this would make
>>>>>>> it very difficult for the user to find all those constraints applying
>>>>>>> to a given container element type (esp. as type arguments could switch
>>>>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>>>>>
>>>>>>> --Gunnar
>>>>>>>
>>>>>>>
>>>>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>>> The various descriptor types return constraint information from the
>>>>>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>>>>>> encountered a puzzle which I cannot solve using the current version of
>>>>>>>> the specification. Consider:
>>>>>>>>
>>>>>>>> public interface User {
>>>>>>>>   Set<@NotEmpty String> getRoles();
>>>>>>>> }
>>>>>>>>
>>>>>>>> public class Roles implements Set<String> {
>>>>>>>>  ...
>>>>>>>> }
>>>>>>>>
>>>>>>>> public class UserImpl implements User {
>>>>>>>>   @Override
>>>>>>>>   public Roles getRoles();
>>>>>>>> }
>>>>>>>>
>>>>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>>>>> extractor is applicable to Roles, but because the return value of the
>>>>>>>> getter has been narrowed, there is no type parameter at this point in
>>>>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>>>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>>>>> probably a question we need to resolve, unless I have missed something
>>>>>>>> that should be obvious. I think this could be solved if the CETD were
>>>>>>>> to explicitly specify the type with which its argument index is
>>>>>>>> associated. The alternative would be to require a custom
>>>>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Matt
>>>>>>>> _______________________________________________
>>>>>>>> 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
>> _______________________________________________
>> 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 mbenson at apache.org  Tue Jun 20 16:38:00 2017
From: mbenson at apache.org (Matt Benson)
Date: Tue, 20 Jun 2017 15:38:00 -0500
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CADGJaX9up8m0CHMT6G8aCA_CT-=BB0xxemmCK==5eDWHgVL3xg@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
	<CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
	<CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
	<CADGJaX_HEmmmD_1-7nZ+ibcFp9vVeRtd3WwrFFw=ny7UFHzHNw@mail.gmail.com>
	<CADGJaX9up8m0CHMT6G8aCA_CT-=BB0xxemmCK==5eDWHgVL3xg@mail.gmail.com>
Message-ID: <CAE9L6G28ytky1TDfqDdaf678JxQftLyFtRYQv+82OVHWNARjig@mail.gmail.com>

AFAICT this looks good and addresses my concern about the container
class while also clarifying the intent of
ContainerElementTypeDescriptor#getElementClass().

Thanks,
Matt

On Tue, Jun 20, 2017 at 3:06 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Matt,
>
> I've prepared a PR with the discussed change to the metadata API:
> https://github.com/beanvalidation/beanvalidation-spec/pull/209
>
> Could you take a look and let me know whether it satisfies the
> requirements as you see them? It has been a long day here and I'll
> think about it again tomorrow with a fresh mind; any feedback you may
> have is very welcome.
>
> Thanks!
>
> 2017-06-20 15:04 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>> 2017-06-19 17:50 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Mon, Jun 19, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> Hi,
>>>>
>>>> Putting constraints to type parameters of generic types or methods as
>>>> well as putting constraints to type arguments in extends/implements
>>>> clauses isn't supported as of BV 2.0. I thought that's mentioned
>>>> somewhere in the spec, but couldn't find it during a quick check. If
>>>> it's indeed missing, I'll add it. We can look into this for 2.1 of
>>>> course.
>>>
>>> I'm pretty sure wildcards are explicitly mentioned as not being
>>> supported, and bounds are mentioned there. I don't remember type vars
>>> being included in that. You say "as of BV 2.0." Can I take that to
>>> mean that you think it's at least possible that this might be
>>> something the spec should support in the future? Is this basically a
>>> case of limiting feature creep so that we can finish this iteration
>>> ASAP?
>>
>> Yes, it's definitely something we can consider to support in a future
>> revision. But for BV 2.0 it's too late to add it, as I'll have to
>> submit the Proposed Final Draft tomorrow or say latest Thursday. While
>> we can do some more adjustments until Final Approval Ballot, this may
>> only be corrections and clarifications of already added stuff at this
>> point unfortunately.
>>
>> For sure we should explore this on the implementation level, so we
>> have some experiences already when starting to work on the next spec
>> revision.
>>
>>
>>>
>>>>
>>>>> I also suspect that it will make sense to introduce a <container>
>>>>> element to the XML mapping schema with an optional type, to
>>>>> (optionally?) house the <container-element-type> elements.
>>>>
>>>
>>> If we've established that the ContainerElementType needs the container
>>> type to be certain of providing enough information to locate the
>>> relevant value extractor, then consider the XML mapping. Say we have:
>>>
>>> interface ILookup {
>>>   Map<String, String> getLookup();
>>> }
>>>
>>> class LookupTable extends Hashtable<String, String> {
>>> }
>>>
>>> class LookupImpl implements ILookup {
>>>   private LookupTable lookupTable;
>>>
>>>   LookupTable getLookup() {
>>>     return lookupTable;
>>>   }
>>> }
>>>
>>> And we want to constrain the type parameters of the Map in XML:
>>>
>>> <bean class="ILookup">
>>>   <getter name="getLookup">
>>>     <!-- TBD -->
>>>   </getter>
>>> </bean>
>>>
>>> We could do:
>>>
>>> <container-element-type container-type="java.util.Map" type-argument-index="0">
>>>   <constraint annotation="NotNull" />
>>>   <constraint annotation="NotBlank" />
>>> </container-element-type>
>>> <container-element-type container-type="java.util.Map" type-argument-index="1">
>>>   <constraint annotation="NotBlank" />
>>> </container-element-type>
>>
>> I don't think there's a need to specify the container type in this
>> case, as this can be obtained from the configured field, method etc.
>> So for configuring ILookup#getLookup(), it'd look like this with the
>> currently proposed schema:
>>
>>     <bean class="ILookup">
>>         <getter name="lookup">
>>             <container-element-type type-argument-index="0">
>>                 <constraint annotation="NotNull" />
>>                 <constraint annotation="NotBlank" />
>>             </container-element-type>
>>             <container-element-type type-argument-index="1">
>>                 <constraint annotation="NotBlank" />
>>             </container-element-type>
>>         </getter>
>>     </bean>
>>
>> I.e. this is about Map<String, String> as that's the type of
>> ILookup#getLookup().
>>
>>>
>>> ... and for simplicity's sake, since the typical container likely has
>>> a single element type, we probably should continue to support this.
>>> But should we also allow, e.g.:
>>>
>>> <container type="java.util.Map">
>>>   <container-element-type type-argument-index="0">
>>>     <constraint annotation="NotNull" />
>>>     <constraint annotation="NotBlank" />
>>>   </container-element-type>
>>>   <container-element-type type-argument-index="1">
>>>     <constraint annotation="NotBlank" />
>>>   </container-element-type>
>>> </container-type>
>>
>> I think it's answered by my previous comment?
>>
>>>
>>> WRT the optionality of the type argument index, it's clear that for
>>> containers with a single element type, that could be omitted. Is it
>>> further intended that where the list of container-element-type
>>> elements has a length matching the number of type variables declared
>>> on the container type, these should be understood to specify a 1:1
>>> ordered correspondence? If so, is there a place (and hopefully a more
>>> intelligible way ;) ) to clarify that in the spec?
>>
>> That behaviour is not intended. I don't like the idea of relying on
>> ordering, as it'd require you to specify (empty) container element
>> type nodes for all type arguments, also if only one is to be
>> constrained.
>>
>> That's what we currently say in the spec:
>>
>>     "The type-argument-index is used to specify the index of the
>> configured type argument. The type-argument-index can be omitted, if
>> the container element type has exactly one type argument. [...] If an
>> invalid container type element configuration is detected, a
>> ValidationException is raised. This includes the following
>> configuration errors:
>>
>>     * The type of the surrounding element (field, getter etc.) has no
>> type arguments.
>>     * The type of the surrounding element has no type argument with
>> the index given via type-argument-index.
>>     * The type of the surrounding element has multiple type arguments
>> and no index is given via type-argument-index.
>>     * The same type argument of the surrounding element is configured
>> multiple times."
>>
>> Do you think this is clear enough or should we change the wording in some way?
>>
>>
>>>
>>> Matt
>>>
>>>> Could you elaborate on that point a bit? What exactly is the use case for this?
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>>> 2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> More thoughts in this vein:
>>>>>
>>>>> At first I thought that method overrides were the only place you might
>>>>> have > 1 container class represented, but why wouldn't we support
>>>>> e.g.:
>>>>>
>>>>> class Roles implements Set<@NotEmpty String> {
>>>>> ...
>>>>> }
>>>>>
>>>>> ? Then it'd be possible to extract container elements even at the bean level.
>>>>>
>>>>> Next, consider parameters. the spec currently says that wildcards
>>>>> aren't supported, but what about:
>>>>>
>>>>> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);
>>>>>
>>>>> In this way a parameter could expose multiple container types (pretend
>>>>> I used unrelated interfaces if that helps). We could save generic
>>>>> extends support for a future iteration of the spec, but semantically
>>>>> it makes sense to me so I'd expect we'll eventually have to do it in
>>>>> any case. I suppose you could even do fields if you annotated some
>>>>> type parameter of the bean.
>>>>>
>>>>> I also suspect that it will make sense to introduce a <container>
>>>>> element to the XML mapping schema with an optional type, to
>>>>> (optionally?) house the <container-element-type> elements.
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>>>> Hi Matt,
>>>>>>>>
>>>>>>>> Thanks for bringing this up!
>>>>>>>>
>>>>>>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>>>>>>> one thing needed, but it's not enough. Currently we have
>>>>>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>>>>>> PropertyDescriptor etc. which returns the container element
>>>>>>>> descriptors in the order of type arguments. This also doesn't really
>>>>>>>> fit for User#getRoles().
>>>>>>>>
>>>>>>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>>>>>>> and then each element from that set exposes containerClass and
>>>>>>>> typeArgumentIndex as you suggest.
>>>>>>>>
>>>>>>>> It's getting a bit tricky though to get the effective set of all
>>>>>>>> container element constraints. Eg. say we have:
>>>>>>>>
>>>>>>>>     public interface IUserBase {
>>>>>>>>         Set<@NotBlank String> getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     public interface IUser extends IUserBase {
>>>>>>>>         Set<@NotEmpty String> getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     public class UserImpl implements IUser {
>>>>>>>>         Roles getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>> Then when querying
>>>>>>>>
>>>>>>>>     validator.getConstraintsForClass( IUser.class )
>>>>>>>>         .getConstraintsForProperty( "roles" )
>>>>>>>>         .getContainerElementTypes();
>>>>>>>>
>>>>>>>> We'd get a set with these elements:
>>>>>>>>
>>>>>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>>>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>>>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>>>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>>>>>> DEFINED_LOCALLY)}
>>>>>>>>
>>>>>>>
>>>>>>> I was thinking that the containerClass would be Set.class.
>>>>>>
>>>>>> Yes, you are right of course.
>>>>>>
>>>>>>>
>>>>>>>> The descriptor for IUser would have to return the inherited @NotBlank
>>>>>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>>>>>> would have to examine all ContainerElementDescriptors and just collect
>>>>>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>>>>>> duplicates.
>>>>>>>>
>>>>>>>
>>>>>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>>>>>> reduced to unique type parameters, but I'm not sure I'm following your
>>>>>>> argument above. My suggestion above (containerClass=Set.class) would
>>>>>>> give an easy way to identify what needs to be collapsed where: onto
>>>>>>> Set<[0]>. Consider this:
>>>>>>>
>>>>>>> public class Roles<S extends System> implements Set<String> {
>>>>>>>   public S getSystem() {
>>>>>>>     ...
>>>>>>>   }
>>>>>>>   ...
>>>>>>> }
>>>>>>>
>>>>>>> public class UserImpl implements IUser {
>>>>>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>>>>>     ...
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> Here Roles would implement a custom container type on top of Iterable
>>>>>>> via Set, so the method would return separate ContainerTypeElements for
>>>>>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>>>>>
>>>>>> Yes, it does.
>>>>>>
>>>>>> And in my previous example we'd have getContainerElementTypes() return
>>>>>> a set with one descriptor:
>>>>>>
>>>>>> ContainerElementDescriptor(containerClass=Set.class,
>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>>>>>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>>>>>
>>>>>> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>>>>>>
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>>> The alternative would be to explicitly redeclare
>>>>>>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>>>>>>> it doesn't expose constraints from the hierarchy. But this would make
>>>>>>>> it very difficult for the user to find all those constraints applying
>>>>>>>> to a given container element type (esp. as type arguments could switch
>>>>>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>>>>>>
>>>>>>>> --Gunnar
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>>>> The various descriptor types return constraint information from the
>>>>>>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>>>>>>> encountered a puzzle which I cannot solve using the current version of
>>>>>>>>> the specification. Consider:
>>>>>>>>>
>>>>>>>>> public interface User {
>>>>>>>>>   Set<@NotEmpty String> getRoles();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public class Roles implements Set<String> {
>>>>>>>>>  ...
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public class UserImpl implements User {
>>>>>>>>>   @Override
>>>>>>>>>   public Roles getRoles();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>>>>>> extractor is applicable to Roles, but because the return value of the
>>>>>>>>> getter has been narrowed, there is no type parameter at this point in
>>>>>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>>>>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>>>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>>>>>> probably a question we need to resolve, unless I have missed something
>>>>>>>>> that should be obvious. I think this could be solved if the CETD were
>>>>>>>>> to explicitly specify the type with which its argument index is
>>>>>>>>> associated. The alternative would be to require a custom
>>>>>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Matt
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>> _______________________________________________
>>> 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  Wed Jun 21 03:48:08 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 21 Jun 2017 09:48:08 +0200
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
	<CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
	<CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
Message-ID: <CADGJaX9Nf+6JCa2p_p0hB5ncF7a2bJCK_RdXdy_EThg+jX0Sfw@mail.gmail.com>

> I'm pretty sure wildcards are explicitly mentioned as not being
> supported, and bounds are mentioned there.

I've just prepared
https://github.com/beanvalidation/beanvalidation-spec/pull/210 to
clarify that area.

It says that container element constraints and @Valid are not
supported on the type parameters of generic types and methods as well
as on type arguments with the extends/implements clauses of type
definitions. Implementations are free to experiment with this and we
may lift this limitation in a future revision.

Note that I've removed the note of container element constraints being
unsupported on wildcard type arguments. The reason being that we don't
say something similar for regular (property etc.) constraints. The
spec has been a bit vague on support for constraints on
property/parameter etc. types that are (bounded) wildcards or refer to
type parameters since 1.0. We probably should clarify it at some
point, but it should be done in a general fashion, so I think there's
no need for now to be overly specific for the case of container
element constraints.


2017-06-19 17:50 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Mon, Jun 19, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi,
>>
>> Putting constraints to type parameters of generic types or methods as
>> well as putting constraints to type arguments in extends/implements
>> clauses isn't supported as of BV 2.0. I thought that's mentioned
>> somewhere in the spec, but couldn't find it during a quick check. If
>> it's indeed missing, I'll add it. We can look into this for 2.1 of
>> course.
>
> I'm pretty sure wildcards are explicitly mentioned as not being
> supported, and bounds are mentioned there. I don't remember type vars
> being included in that. You say "as of BV 2.0." Can I take that to
> mean that you think it's at least possible that this might be
> something the spec should support in the future? Is this basically a
> case of limiting feature creep so that we can finish this iteration
> ASAP?
>
>>
>>> I also suspect that it will make sense to introduce a <container>
>>> element to the XML mapping schema with an optional type, to
>>> (optionally?) house the <container-element-type> elements.
>>
>
> If we've established that the ContainerElementType needs the container
> type to be certain of providing enough information to locate the
> relevant value extractor, then consider the XML mapping. Say we have:
>
> interface ILookup {
>   Map<String, String> getLookup();
> }
>
> class LookupTable extends Hashtable<String, String> {
> }
>
> class LookupImpl implements ILookup {
>   private LookupTable lookupTable;
>
>   LookupTable getLookup() {
>     return lookupTable;
>   }
> }
>
> And we want to constrain the type parameters of the Map in XML:
>
> <bean class="ILookup">
>   <getter name="getLookup">
>     <!-- TBD -->
>   </getter>
> </bean>
>
> We could do:
>
> <container-element-type container-type="java.util.Map" type-argument-index="0">
>   <constraint annotation="NotNull" />
>   <constraint annotation="NotBlank" />
> </container-element-type>
> <container-element-type container-type="java.util.Map" type-argument-index="1">
>   <constraint annotation="NotBlank" />
> </container-element-type>
>
> ... and for simplicity's sake, since the typical container likely has
> a single element type, we probably should continue to support this.
> But should we also allow, e.g.:
>
> <container type="java.util.Map">
>   <container-element-type type-argument-index="0">
>     <constraint annotation="NotNull" />
>     <constraint annotation="NotBlank" />
>   </container-element-type>
>   <container-element-type type-argument-index="1">
>     <constraint annotation="NotBlank" />
>   </container-element-type>
> </container-type>
>
> WRT the optionality of the type argument index, it's clear that for
> containers with a single element type, that could be omitted. Is it
> further intended that where the list of container-element-type
> elements has a length matching the number of type variables declared
> on the container type, these should be understood to specify a 1:1
> ordered correspondence? If so, is there a place (and hopefully a more
> intelligible way ;) ) to clarify that in the spec?
>
> Matt
>
>> Could you elaborate on that point a bit? What exactly is the use case for this?
>>
>> --Gunnar
>>
>>
>>
>> 2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> More thoughts in this vein:
>>>
>>> At first I thought that method overrides were the only place you might
>>> have > 1 container class represented, but why wouldn't we support
>>> e.g.:
>>>
>>> class Roles implements Set<@NotEmpty String> {
>>> ...
>>> }
>>>
>>> ? Then it'd be possible to extract container elements even at the bean level.
>>>
>>> Next, consider parameters. the spec currently says that wildcards
>>> aren't supported, but what about:
>>>
>>> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);
>>>
>>> In this way a parameter could expose multiple container types (pretend
>>> I used unrelated interfaces if that helps). We could save generic
>>> extends support for a future iteration of the spec, but semantically
>>> it makes sense to me so I'd expect we'll eventually have to do it in
>>> any case. I suppose you could even do fields if you annotated some
>>> type parameter of the bean.
>>>
>>> I also suspect that it will make sense to introduce a <container>
>>> element to the XML mapping schema with an optional type, to
>>> (optionally?) house the <container-element-type> elements.
>>>
>>> Matt
>>>
>>>
>>> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>> Hi Matt,
>>>>>>
>>>>>> Thanks for bringing this up!
>>>>>>
>>>>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>>>>> one thing needed, but it's not enough. Currently we have
>>>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>>>> PropertyDescriptor etc. which returns the container element
>>>>>> descriptors in the order of type arguments. This also doesn't really
>>>>>> fit for User#getRoles().
>>>>>>
>>>>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>>>>> and then each element from that set exposes containerClass and
>>>>>> typeArgumentIndex as you suggest.
>>>>>>
>>>>>> It's getting a bit tricky though to get the effective set of all
>>>>>> container element constraints. Eg. say we have:
>>>>>>
>>>>>>     public interface IUserBase {
>>>>>>         Set<@NotBlank String> getRoles();
>>>>>>     }
>>>>>>
>>>>>>     public interface IUser extends IUserBase {
>>>>>>         Set<@NotEmpty String> getRoles();
>>>>>>     }
>>>>>>
>>>>>>     public class UserImpl implements IUser {
>>>>>>         Roles getRoles();
>>>>>>     }
>>>>>>
>>>>>> Then when querying
>>>>>>
>>>>>>     validator.getConstraintsForClass( IUser.class )
>>>>>>         .getConstraintsForProperty( "roles" )
>>>>>>         .getContainerElementTypes();
>>>>>>
>>>>>> We'd get a set with these elements:
>>>>>>
>>>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>>>> DEFINED_LOCALLY)}
>>>>>>
>>>>>
>>>>> I was thinking that the containerClass would be Set.class.
>>>>
>>>> Yes, you are right of course.
>>>>
>>>>>
>>>>>> The descriptor for IUser would have to return the inherited @NotBlank
>>>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>>>> would have to examine all ContainerElementDescriptors and just collect
>>>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>>>> duplicates.
>>>>>>
>>>>>
>>>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>>>> reduced to unique type parameters, but I'm not sure I'm following your
>>>>> argument above. My suggestion above (containerClass=Set.class) would
>>>>> give an easy way to identify what needs to be collapsed where: onto
>>>>> Set<[0]>. Consider this:
>>>>>
>>>>> public class Roles<S extends System> implements Set<String> {
>>>>>   public S getSystem() {
>>>>>     ...
>>>>>   }
>>>>>   ...
>>>>> }
>>>>>
>>>>> public class UserImpl implements IUser {
>>>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>>>     ...
>>>>>   }
>>>>> }
>>>>>
>>>>> Here Roles would implement a custom container type on top of Iterable
>>>>> via Set, so the method would return separate ContainerTypeElements for
>>>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>>>
>>>> Yes, it does.
>>>>
>>>> And in my previous example we'd have getContainerElementTypes() return
>>>> a set with one descriptor:
>>>>
>>>> ContainerElementDescriptor(containerClass=Set.class,
>>>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>>>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>>>
>>>> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>>>>
>>>>>
>>>>> Matt
>>>>>
>>>>>> The alternative would be to explicitly redeclare
>>>>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>>>>> it doesn't expose constraints from the hierarchy. But this would make
>>>>>> it very difficult for the user to find all those constraints applying
>>>>>> to a given container element type (esp. as type arguments could switch
>>>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>>>>
>>>>>> --Gunnar
>>>>>>
>>>>>>
>>>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>> The various descriptor types return constraint information from the
>>>>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>>>>> encountered a puzzle which I cannot solve using the current version of
>>>>>>> the specification. Consider:
>>>>>>>
>>>>>>> public interface User {
>>>>>>>   Set<@NotEmpty String> getRoles();
>>>>>>> }
>>>>>>>
>>>>>>> public class Roles implements Set<String> {
>>>>>>>  ...
>>>>>>> }
>>>>>>>
>>>>>>> public class UserImpl implements User {
>>>>>>>   @Override
>>>>>>>   public Roles getRoles();
>>>>>>> }
>>>>>>>
>>>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>>>> extractor is applicable to Roles, but because the return value of the
>>>>>>> getter has been narrowed, there is no type parameter at this point in
>>>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>>>> probably a question we need to resolve, unless I have missed something
>>>>>>> that should be obvious. I think this could be solved if the CETD were
>>>>>>> to explicitly specify the type with which its argument index is
>>>>>>> associated. The alternative would be to require a custom
>>>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matt
>>>>>>> _______________________________________________
>>>>>>> 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
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Wed Jun 21 03:52:38 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 21 Jun 2017 09:52:38 +0200
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CAE9L6G2Py2-4JnPn42K2nb9ToMtFnjcd+vo76bMDv74Xi7QCTQ@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
	<CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
	<CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
	<CADGJaX_HEmmmD_1-7nZ+ibcFp9vVeRtd3WwrFFw=ny7UFHzHNw@mail.gmail.com>
	<CAE9L6G2Py2-4JnPn42K2nb9ToMtFnjcd+vo76bMDv74Xi7QCTQ@mail.gmail.com>
Message-ID: <CADGJaX-4ceC3hPuG6sF9Ohd5Sg+QwGgVwyh504BVhhQf-qbDgA@mail.gmail.com>

> My thinking was to make it possible for a user to configure container
> element constraints for various levels of the inheritance hierarchy
> for a given e.g. method return type. So continuing the lookup example,
> perhaps we want to constrain the key of a LookupTable only for
> LookupImpl and not for every implementation of ILookup.

Ah, got you.

I don't think it's something we should support really, as it'd abandon
the symmetry of capabilities of annotations and XML. For such use
case, LookupImpl#getLookup() should declare a return type of Map<...,
...> itself, so container element constraints can be applied via
<beanClass class="LookupImpl">...</beanClass>.

2017-06-20 22:36 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Tue, Jun 20, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 2017-06-19 17:50 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Mon, Jun 19, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> Hi,
>>>>
>>>> Putting constraints to type parameters of generic types or methods as
>>>> well as putting constraints to type arguments in extends/implements
>>>> clauses isn't supported as of BV 2.0. I thought that's mentioned
>>>> somewhere in the spec, but couldn't find it during a quick check. If
>>>> it's indeed missing, I'll add it. We can look into this for 2.1 of
>>>> course.
>>>
>>> I'm pretty sure wildcards are explicitly mentioned as not being
>>> supported, and bounds are mentioned there. I don't remember type vars
>>> being included in that. You say "as of BV 2.0." Can I take that to
>>> mean that you think it's at least possible that this might be
>>> something the spec should support in the future? Is this basically a
>>> case of limiting feature creep so that we can finish this iteration
>>> ASAP?
>>
>> Yes, it's definitely something we can consider to support in a future
>> revision. But for BV 2.0 it's too late to add it, as I'll have to
>> submit the Proposed Final Draft tomorrow or say latest Thursday. While
>> we can do some more adjustments until Final Approval Ballot, this may
>> only be corrections and clarifications of already added stuff at this
>> point unfortunately.
>>
>> For sure we should explore this on the implementation level, so we
>> have some experiences already when starting to work on the next spec
>> revision.
>>
>>
>>>
>>>>
>>>>> I also suspect that it will make sense to introduce a <container>
>>>>> element to the XML mapping schema with an optional type, to
>>>>> (optionally?) house the <container-element-type> elements.
>>>>
>>>
>>> If we've established that the ContainerElementType needs the container
>>> type to be certain of providing enough information to locate the
>>> relevant value extractor, then consider the XML mapping. Say we have:
>>>
>>> interface ILookup {
>>>   Map<String, String> getLookup();
>>> }
>>>
>>> class LookupTable extends Hashtable<String, String> {
>>> }
>>>
>>> class LookupImpl implements ILookup {
>>>   private LookupTable lookupTable;
>>>
>>>   LookupTable getLookup() {
>>>     return lookupTable;
>>>   }
>>> }
>>>
>>> And we want to constrain the type parameters of the Map in XML:
>>>
>>> <bean class="ILookup">
>>>   <getter name="getLookup">
>>>     <!-- TBD -->
>>>   </getter>
>>> </bean>
>>>
>>> We could do:
>>>
>>> <container-element-type container-type="java.util.Map" type-argument-index="0">
>>>   <constraint annotation="NotNull" />
>>>   <constraint annotation="NotBlank" />
>>> </container-element-type>
>>> <container-element-type container-type="java.util.Map" type-argument-index="1">
>>>   <constraint annotation="NotBlank" />
>>> </container-element-type>
>>
>> I don't think there's a need to specify the container type in this
>> case, as this can be obtained from the configured field, method etc.
>> So for configuring ILookup#getLookup(), it'd look like this with the
>> currently proposed schema:
>>
>>     <bean class="ILookup">
>>         <getter name="lookup">
>>             <container-element-type type-argument-index="0">
>>                 <constraint annotation="NotNull" />
>>                 <constraint annotation="NotBlank" />
>>             </container-element-type>
>>             <container-element-type type-argument-index="1">
>>                 <constraint annotation="NotBlank" />
>>             </container-element-type>
>>         </getter>
>>     </bean>
>>
>> I.e. this is about Map<String, String> as that's the type of
>> ILookup#getLookup().
>>
>>>
>>> ... and for simplicity's sake, since the typical container likely has
>>> a single element type, we probably should continue to support this.
>>> But should we also allow, e.g.:
>>>
>>> <container type="java.util.Map">
>>>   <container-element-type type-argument-index="0">
>>>     <constraint annotation="NotNull" />
>>>     <constraint annotation="NotBlank" />
>>>   </container-element-type>
>>>   <container-element-type type-argument-index="1">
>>>     <constraint annotation="NotBlank" />
>>>   </container-element-type>
>>> </container-type>
>>
>> I think it's answered by my previous comment?
>>
>
> My thinking was to make it possible for a user to configure container
> element constraints for various levels of the inheritance hierarchy
> for a given e.g. method return type. So continuing the lookup example,
> perhaps we want to constrain the key of a LookupTable only for
> LookupImpl and not for every implementation of ILookup. Given the time
> issue though we can leave this alone for now.
>
>>>
>>> WRT the optionality of the type argument index, it's clear that for
>>> containers with a single element type, that could be omitted. Is it
>>> further intended that where the list of container-element-type
>>> elements has a length matching the number of type variables declared
>>> on the container type, these should be understood to specify a 1:1
>>> ordered correspondence? If so, is there a place (and hopefully a more
>>> intelligible way ;) ) to clarify that in the spec?
>>
>> That behaviour is not intended. I don't like the idea of relying on
>> ordering, as it'd require you to specify (empty) container element
>> type nodes for all type arguments, also if only one is to be
>> constrained.
>>
>> That's what we currently say in the spec:
>>
>>     "The type-argument-index is used to specify the index of the
>> configured type argument. The type-argument-index can be omitted, if
>> the container element type has exactly one type argument. [...] If an
>> invalid container type element configuration is detected, a
>> ValidationException is raised. This includes the following
>> configuration errors:
>>
>>     * The type of the surrounding element (field, getter etc.) has no
>> type arguments.
>>     * The type of the surrounding element has no type argument with
>> the index given via type-argument-index.
>>     * The type of the surrounding element has multiple type arguments
>> and no index is given via type-argument-index.
>>     * The same type argument of the surrounding element is configured
>> multiple times."
>>
>> Do you think this is clear enough or should we change the wording in some way?
>>
>
> Seems okay to me.
>
> Matt
>
>>
>>>
>>> Matt
>>>
>>>> Could you elaborate on that point a bit? What exactly is the use case for this?
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>>> 2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> More thoughts in this vein:
>>>>>
>>>>> At first I thought that method overrides were the only place you might
>>>>> have > 1 container class represented, but why wouldn't we support
>>>>> e.g.:
>>>>>
>>>>> class Roles implements Set<@NotEmpty String> {
>>>>> ...
>>>>> }
>>>>>
>>>>> ? Then it'd be possible to extract container elements even at the bean level.
>>>>>
>>>>> Next, consider parameters. the spec currently says that wildcards
>>>>> aren't supported, but what about:
>>>>>
>>>>> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void foo(X);
>>>>>
>>>>> In this way a parameter could expose multiple container types (pretend
>>>>> I used unrelated interfaces if that helps). We could save generic
>>>>> extends support for a future iteration of the spec, but semantically
>>>>> it makes sense to me so I'd expect we'll eventually have to do it in
>>>>> any case. I suppose you could even do fields if you annotated some
>>>>> type parameter of the bean.
>>>>>
>>>>> I also suspect that it will make sense to introduce a <container>
>>>>> element to the XML mapping schema with an optional type, to
>>>>> (optionally?) house the <container-element-type> elements.
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>>>> Hi Matt,
>>>>>>>>
>>>>>>>> Thanks for bringing this up!
>>>>>>>>
>>>>>>>> I think adding ContainerElementTypeDescriptor#getContainerClass() is
>>>>>>>> one thing needed, but it's not enough. Currently we have
>>>>>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>>>>>> PropertyDescriptor etc. which returns the container element
>>>>>>>> descriptors in the order of type arguments. This also doesn't really
>>>>>>>> fit for User#getRoles().
>>>>>>>>
>>>>>>>> So we could make this a Set<ContainerElementTypeDescriptor> instead,
>>>>>>>> and then each element from that set exposes containerClass and
>>>>>>>> typeArgumentIndex as you suggest.
>>>>>>>>
>>>>>>>> It's getting a bit tricky though to get the effective set of all
>>>>>>>> container element constraints. Eg. say we have:
>>>>>>>>
>>>>>>>>     public interface IUserBase {
>>>>>>>>         Set<@NotBlank String> getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     public interface IUser extends IUserBase {
>>>>>>>>         Set<@NotEmpty String> getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     public class UserImpl implements IUser {
>>>>>>>>         Roles getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>> Then when querying
>>>>>>>>
>>>>>>>>     validator.getConstraintsForClass( IUser.class )
>>>>>>>>         .getConstraintsForProperty( "roles" )
>>>>>>>>         .getContainerElementTypes();
>>>>>>>>
>>>>>>>> We'd get a set with these elements:
>>>>>>>>
>>>>>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>>>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>>>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>>>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>>>>>> DEFINED_LOCALLY)}
>>>>>>>>
>>>>>>>
>>>>>>> I was thinking that the containerClass would be Set.class.
>>>>>>
>>>>>> Yes, you are right of course.
>>>>>>
>>>>>>>
>>>>>>>> The descriptor for IUser would have to return the inherited @NotBlank
>>>>>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>>>>>> would have to examine all ContainerElementDescriptors and just collect
>>>>>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>>>>>> duplicates.
>>>>>>>>
>>>>>>>
>>>>>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>>>>>> reduced to unique type parameters, but I'm not sure I'm following your
>>>>>>> argument above. My suggestion above (containerClass=Set.class) would
>>>>>>> give an easy way to identify what needs to be collapsed where: onto
>>>>>>> Set<[0]>. Consider this:
>>>>>>>
>>>>>>> public class Roles<S extends System> implements Set<String> {
>>>>>>>   public S getSystem() {
>>>>>>>     ...
>>>>>>>   }
>>>>>>>   ...
>>>>>>> }
>>>>>>>
>>>>>>> public class UserImpl implements IUser {
>>>>>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>>>>>     ...
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> Here Roles would implement a custom container type on top of Iterable
>>>>>>> via Set, so the method would return separate ContainerTypeElements for
>>>>>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>>>>>
>>>>>> Yes, it does.
>>>>>>
>>>>>> And in my previous example we'd have getContainerElementTypes() return
>>>>>> a set with one descriptor:
>>>>>>
>>>>>> ContainerElementDescriptor(containerClass=Set.class,
>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>>>>>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>>>>>
>>>>>> (both constraints are defined in the hierarchy from the perspective of UserImpl)
>>>>>>
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>>> The alternative would be to explicitly redeclare
>>>>>>>> getConstraintDescriptors() for ContainerElementDescriptor and say that
>>>>>>>> it doesn't expose constraints from the hierarchy. But this would make
>>>>>>>> it very difficult for the user to find all those constraints applying
>>>>>>>> to a given container element type (esp. as type arguments could switch
>>>>>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for this issue.
>>>>>>>>
>>>>>>>> --Gunnar
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>>>> The various descriptor types return constraint information from the
>>>>>>>>> entire hierarchy by default. However, in thinking about this I quickly
>>>>>>>>> encountered a puzzle which I cannot solve using the current version of
>>>>>>>>> the specification. Consider:
>>>>>>>>>
>>>>>>>>> public interface User {
>>>>>>>>>   Set<@NotEmpty String> getRoles();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public class Roles implements Set<String> {
>>>>>>>>>  ...
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public class UserImpl implements User {
>>>>>>>>>   @Override
>>>>>>>>>   public Roles getRoles();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>>>>>> extractor is applicable to Roles, but because the return value of the
>>>>>>>>> getter has been narrowed, there is no type parameter at this point in
>>>>>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type Roles
>>>>>>>>> to return a ContainerElementTypeDescriptor with index 0. This example
>>>>>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>>>>>> probably a question we need to resolve, unless I have missed something
>>>>>>>>> that should be obvious. I think this could be solved if the CETD were
>>>>>>>>> to explicitly specify the type with which its argument index is
>>>>>>>>> associated. The alternative would be to require a custom
>>>>>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Matt
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>> _______________________________________________
>>> 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  Wed Jun 21 05:50:25 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 21 Jun 2017 11:50:25 +0200
Subject: [bv-dev] @Past(orPresent=true) -> @PastOrPresent?
Message-ID: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>

Hi all,

A colleague of mine reviewing the BV 2.0 changes pointed out an
inconsistency in the added/modified constraints.

As per the community poll we have now @NegativeOrZero and
@PositiveOrZero, whereas we still have the orPresent() option on @Past
and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
for the sake of consistency?

Now one could argue that having only attributes (orPresent(),
orZero()) is most consistent with other constraints such as
@DigitalMin. But indeed the explicit annotations grew on me over time
as they are a bit shorter to use and, more importantly, better to
read.

It's late in the game, but I feel inclined to extract @PastOrPresent
and @FutureOrPresent. What do you think?

Thanks,

--Gunnar

From mbenson at apache.org  Wed Jun 21 08:31:56 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 21 Jun 2017 07:31:56 -0500
Subject: [bv-dev] Spec question on ContainerElementTypeDescriptor
In-Reply-To: <CADGJaX-4ceC3hPuG6sF9Ohd5Sg+QwGgVwyh504BVhhQf-qbDgA@mail.gmail.com>
References: <CAE9L6G3vT6PxGB6_vFE5GSzYg_xyE97h+7v3k9i+0Kbg6x0ZFA@mail.gmail.com>
	<CADGJaX8jbxG=9aBur3fQez-aA3ien=vGg+MFKVm2GFAve=9E-w@mail.gmail.com>
	<CAE9L6G3VhtnboA45WREyR71Bh3BKYBaHv3cNCB20v5xyUP9JWw@mail.gmail.com>
	<CADGJaX9Bw9MJkHqgbUnNyqJa0v9LTQZsu7=KTZsUJ_wp8Ecz=g@mail.gmail.com>
	<CAE9L6G2Q4WcZyAUzxktcF3-MjoL6UhhLb+WbfRuM8sKc2muneA@mail.gmail.com>
	<CADGJaX_Be7aykRc7EoaE3sMqfX+7X1Axw0ju2+-5OAp0-y0q_A@mail.gmail.com>
	<CAE9L6G0g457oOmH0BJet=co-XEy=hn2XWpf6y2=fqZWS7bffSw@mail.gmail.com>
	<CADGJaX_HEmmmD_1-7nZ+ibcFp9vVeRtd3WwrFFw=ny7UFHzHNw@mail.gmail.com>
	<CAE9L6G2Py2-4JnPn42K2nb9ToMtFnjcd+vo76bMDv74Xi7QCTQ@mail.gmail.com>
	<CADGJaX-4ceC3hPuG6sF9Ohd5Sg+QwGgVwyh504BVhhQf-qbDgA@mail.gmail.com>
Message-ID: <CAE9L6G1STuN9rJ7-vKG=4YMn4hctZH8mwAAmAP0Z-eGtb-uSAg@mail.gmail.com>

On Jun 21, 2017 2:58 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> My thinking was to make it possible for a user to configure container
> element constraints for various levels of the inheritance hierarchy
> for a given e.g. method return type. So continuing the lookup example,
> perhaps we want to constrain the key of a LookupTable only for
> LookupImpl and not for every implementation of ILookup.

Ah, got you.

I don't think it's something we should support really, as it'd abandon
the symmetry of capabilities of annotations and XML. For such use
case, LookupImpl#getLookup() should declare a return type of Map<...,
...> itself, so container element constraints can be applied via
<beanClass class="LookupImpl">...</beanClass>.


I suppose allowing a particular XML class configuration to target a
superclass method in the suggested manner would confer an advantage not
available to the annotation based config. Let's finish it up then. :-)

Matt


2017-06-20 22:36 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Tue, Jun 20, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>> 2017-06-19 17:50 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Mon, Jun 19, 2017 at 8:04 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>>>> Hi,
>>>>
>>>> Putting constraints to type parameters of generic types or methods as
>>>> well as putting constraints to type arguments in extends/implements
>>>> clauses isn't supported as of BV 2.0. I thought that's mentioned
>>>> somewhere in the spec, but couldn't find it during a quick check. If
>>>> it's indeed missing, I'll add it. We can look into this for 2.1 of
>>>> course.
>>>
>>> I'm pretty sure wildcards are explicitly mentioned as not being
>>> supported, and bounds are mentioned there. I don't remember type vars
>>> being included in that. You say "as of BV 2.0." Can I take that to
>>> mean that you think it's at least possible that this might be
>>> something the spec should support in the future? Is this basically a
>>> case of limiting feature creep so that we can finish this iteration
>>> ASAP?
>>
>> Yes, it's definitely something we can consider to support in a future
>> revision. But for BV 2.0 it's too late to add it, as I'll have to
>> submit the Proposed Final Draft tomorrow or say latest Thursday. While
>> we can do some more adjustments until Final Approval Ballot, this may
>> only be corrections and clarifications of already added stuff at this
>> point unfortunately.
>>
>> For sure we should explore this on the implementation level, so we
>> have some experiences already when starting to work on the next spec
>> revision.
>>
>>
>>>
>>>>
>>>>> I also suspect that it will make sense to introduce a <container>
>>>>> element to the XML mapping schema with an optional type, to
>>>>> (optionally?) house the <container-element-type> elements.
>>>>
>>>
>>> If we've established that the ContainerElementType needs the container
>>> type to be certain of providing enough information to locate the
>>> relevant value extractor, then consider the XML mapping. Say we have:
>>>
>>> interface ILookup {
>>>   Map<String, String> getLookup();
>>> }
>>>
>>> class LookupTable extends Hashtable<String, String> {
>>> }
>>>
>>> class LookupImpl implements ILookup {
>>>   private LookupTable lookupTable;
>>>
>>>   LookupTable getLookup() {
>>>     return lookupTable;
>>>   }
>>> }
>>>
>>> And we want to constrain the type parameters of the Map in XML:
>>>
>>> <bean class="ILookup">
>>>   <getter name="getLookup">
>>>     <!-- TBD -->
>>>   </getter>
>>> </bean>
>>>
>>> We could do:
>>>
>>> <container-element-type container-type="java.util.Map"
type-argument-index="0">
>>>   <constraint annotation="NotNull" />
>>>   <constraint annotation="NotBlank" />
>>> </container-element-type>
>>> <container-element-type container-type="java.util.Map"
type-argument-index="1">
>>>   <constraint annotation="NotBlank" />
>>> </container-element-type>
>>
>> I don't think there's a need to specify the container type in this
>> case, as this can be obtained from the configured field, method etc.
>> So for configuring ILookup#getLookup(), it'd look like this with the
>> currently proposed schema:
>>
>>     <bean class="ILookup">
>>         <getter name="lookup">
>>             <container-element-type type-argument-index="0">
>>                 <constraint annotation="NotNull" />
>>                 <constraint annotation="NotBlank" />
>>             </container-element-type>
>>             <container-element-type type-argument-index="1">
>>                 <constraint annotation="NotBlank" />
>>             </container-element-type>
>>         </getter>
>>     </bean>
>>
>> I.e. this is about Map<String, String> as that's the type of
>> ILookup#getLookup().
>>
>>>
>>> ... and for simplicity's sake, since the typical container likely has
>>> a single element type, we probably should continue to support this.
>>> But should we also allow, e.g.:
>>>
>>> <container type="java.util.Map">
>>>   <container-element-type type-argument-index="0">
>>>     <constraint annotation="NotNull" />
>>>     <constraint annotation="NotBlank" />
>>>   </container-element-type>
>>>   <container-element-type type-argument-index="1">
>>>     <constraint annotation="NotBlank" />
>>>   </container-element-type>
>>> </container-type>
>>
>> I think it's answered by my previous comment?
>>
>
> My thinking was to make it possible for a user to configure container
> element constraints for various levels of the inheritance hierarchy
> for a given e.g. method return type. So continuing the lookup example,
> perhaps we want to constrain the key of a LookupTable only for
> LookupImpl and not for every implementation of ILookup. Given the time
> issue though we can leave this alone for now.
>
>>>
>>> WRT the optionality of the type argument index, it's clear that for
>>> containers with a single element type, that could be omitted. Is it
>>> further intended that where the list of container-element-type
>>> elements has a length matching the number of type variables declared
>>> on the container type, these should be understood to specify a 1:1
>>> ordered correspondence? If so, is there a place (and hopefully a more
>>> intelligible way ;) ) to clarify that in the spec?
>>
>> That behaviour is not intended. I don't like the idea of relying on
>> ordering, as it'd require you to specify (empty) container element
>> type nodes for all type arguments, also if only one is to be
>> constrained.
>>
>> That's what we currently say in the spec:
>>
>>     "The type-argument-index is used to specify the index of the
>> configured type argument. The type-argument-index can be omitted, if
>> the container element type has exactly one type argument. [...] If an
>> invalid container type element configuration is detected, a
>> ValidationException is raised. This includes the following
>> configuration errors:
>>
>>     * The type of the surrounding element (field, getter etc.) has no
>> type arguments.
>>     * The type of the surrounding element has no type argument with
>> the index given via type-argument-index.
>>     * The type of the surrounding element has multiple type arguments
>> and no index is given via type-argument-index.
>>     * The same type argument of the surrounding element is configured
>> multiple times."
>>
>> Do you think this is clear enough or should we change the wording in
some way?
>>
>
> Seems okay to me.
>
> Matt
>
>>
>>>
>>> Matt
>>>
>>>> Could you elaborate on that point a bit? What exactly is the use case
for this?
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>>> 2017-06-18 17:34 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> More thoughts in this vein:
>>>>>
>>>>> At first I thought that method overrides were the only place you might
>>>>> have > 1 container class represented, but why wouldn't we support
>>>>> e.g.:
>>>>>
>>>>> class Roles implements Set<@NotEmpty String> {
>>>>> ...
>>>>> }
>>>>>
>>>>> ? Then it'd be possible to extract container elements even at the
bean level.
>>>>>
>>>>> Next, consider parameters. the spec currently says that wildcards
>>>>> aren't supported, but what about:
>>>>>
>>>>> <X extends Set<@NotEmpty String> & Iterable<@NotNull String>> void
foo(X);
>>>>>
>>>>> In this way a parameter could expose multiple container types (pretend
>>>>> I used unrelated interfaces if that helps). We could save generic
>>>>> extends support for a future iteration of the spec, but semantically
>>>>> it makes sense to me so I'd expect we'll eventually have to do it in
>>>>> any case. I suppose you could even do fields if you annotated some
>>>>> type parameter of the bean.
>>>>>
>>>>> I also suspect that it will make sense to introduce a <container>
>>>>> element to the XML mapping schema with an optional type, to
>>>>> (optionally?) house the <container-element-type> elements.
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> On Fri, Jun 16, 2017 at 1:38 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>>>>>> 2017-06-16 14:06 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>> On Fri, Jun 16, 2017 at 2:43 AM, Gunnar Morling <
gunnar at hibernate.org> wrote:
>>>>>>>> Hi Matt,
>>>>>>>>
>>>>>>>> Thanks for bringing this up!
>>>>>>>>
>>>>>>>> I think adding ContainerElementTypeDescriptor#getContainerClass()
is
>>>>>>>> one thing needed, but it's not enough. Currently we have
>>>>>>>> List<ContainerElementTypeDescriptor> getContainerElementTypes() on
>>>>>>>> PropertyDescriptor etc. which returns the container element
>>>>>>>> descriptors in the order of type arguments. This also doesn't
really
>>>>>>>> fit for User#getRoles().
>>>>>>>>
>>>>>>>> So we could make this a Set<ContainerElementTypeDescriptor>
instead,
>>>>>>>> and then each element from that set exposes containerClass and
>>>>>>>> typeArgumentIndex as you suggest.
>>>>>>>>
>>>>>>>> It's getting a bit tricky though to get the effective set of all
>>>>>>>> container element constraints. Eg. say we have:
>>>>>>>>
>>>>>>>>     public interface IUserBase {
>>>>>>>>         Set<@NotBlank String> getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     public interface IUser extends IUserBase {
>>>>>>>>         Set<@NotEmpty String> getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     public class UserImpl implements IUser {
>>>>>>>>         Roles getRoles();
>>>>>>>>     }
>>>>>>>>
>>>>>>>> Then when querying
>>>>>>>>
>>>>>>>>     validator.getConstraintsForClass( IUser.class )
>>>>>>>>         .getConstraintsForProperty( "roles" )
>>>>>>>>         .getContainerElementTypes();
>>>>>>>>
>>>>>>>> We'd get a set with these elements:
>>>>>>>>
>>>>>>>>     - ContainerElementDescriptor(containerClass=IUser.class,
>>>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty,
>>>>>>>> defined=DEFINED_LOCALLY), (type=NotBlank,
>>>>>>>> defined=DEFINED_IN_HIERARCHY)}
>>>>>>>>     - ContainerElementDescriptor(containerClass=User.class,
>>>>>>>> typeArgumentIndex=0, constraints={(type=NotBlank, defined=
>>>>>>>> DEFINED_LOCALLY)}
>>>>>>>>
>>>>>>>
>>>>>>> I was thinking that the containerClass would be Set.class.
>>>>>>
>>>>>> Yes, you are right of course.
>>>>>>
>>>>>>>
>>>>>>>> The descriptor for IUser would have to return the inherited
@NotBlank
>>>>>>>> as per the defined semantics of getConstraintDescriptors(). So one
>>>>>>>> would have to examine all ContainerElementDescriptors and just
collect
>>>>>>>> the ones that are DEFINED_LOCALLY to have the effective set without
>>>>>>>> duplicates.
>>>>>>>>
>>>>>>>
>>>>>>> I agree that the set of ContainerElementTypeDescriptors needs to be
>>>>>>> reduced to unique type parameters, but I'm not sure I'm following
your
>>>>>>> argument above. My suggestion above (containerClass=Set.class) would
>>>>>>> give an easy way to identify what needs to be collapsed where: onto
>>>>>>> Set<[0]>. Consider this:
>>>>>>>
>>>>>>> public class Roles<S extends System> implements Set<String> {
>>>>>>>   public S getSystem() {
>>>>>>>     ...
>>>>>>>   }
>>>>>>>   ...
>>>>>>> }
>>>>>>>
>>>>>>> public class UserImpl implements IUser {
>>>>>>>   public Roles<@ValidSystem UserSystem> getRoles() {
>>>>>>>     ...
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> Here Roles would implement a custom container type on top of
Iterable
>>>>>>> via Set, so the method would return separate ContainerTypeElements
for
>>>>>>> Roles<[0]> and Set<[0]>. Does that make sense?
>>>>>>
>>>>>> Yes, it does.
>>>>>>
>>>>>> And in my previous example we'd have getContainerElementTypes()
return
>>>>>> a set with one descriptor:
>>>>>>
>>>>>> ContainerElementDescriptor(containerClass=Set.class,
>>>>>> typeArgumentIndex=0, constraints={(type=NotEmpty, defined=
>>>>>> DEFINED_IN_HIERARCHY), (type=NotBlank, defined=DEFINED_IN_HIERARCHY)}
>>>>>>
>>>>>> (both constraints are defined in the hierarchy from the perspective
of UserImpl)
>>>>>>
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>>> The alternative would be to explicitly redeclare
>>>>>>>> getConstraintDescriptors() for ContainerElementDescriptor and say
that
>>>>>>>> it doesn't expose constraints from the hierarchy. But this would
make
>>>>>>>> it very difficult for the user to find all those constraints
applying
>>>>>>>> to a given container element type (esp. as type arguments could
switch
>>>>>>>> their order in the hierarchy). So that'd not be my preferred route.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> I've filed https://hibernate.atlassian.net/browse/BVAL-655 for
this issue.
>>>>>>>>
>>>>>>>> --Gunnar
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-06-15 17:38 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>>>> The various descriptor types return constraint information from
the
>>>>>>>>> entire hierarchy by default. However, in thinking about this I
quickly
>>>>>>>>> encountered a puzzle which I cannot solve using the current
version of
>>>>>>>>> the specification. Consider:
>>>>>>>>>
>>>>>>>>> public interface User {
>>>>>>>>>   Set<@NotEmpty String> getRoles();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public class Roles implements Set<String> {
>>>>>>>>>  ...
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public class UserImpl implements User {
>>>>>>>>>   @Override
>>>>>>>>>   public Roles getRoles();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> What should the metadata of UserImpl provide? The Iterable value
>>>>>>>>> extractor is applicable to Roles, but because the return value of
the
>>>>>>>>> getter has been narrowed, there is no type parameter at this
point in
>>>>>>>>> the hierarchy. It seems strange for a PropertyDescriptor of type
Roles
>>>>>>>>> to return a ContainerElementTypeDescriptor with index 0. This
example
>>>>>>>>> would AFAICT apply to e.g. javafx StringProperty as well, so it's
>>>>>>>>> probably a question we need to resolve, unless I have missed
something
>>>>>>>>> that should be obvious. I think this could be solved if the CETD
were
>>>>>>>>> to explicitly specify the type with which its argument index is
>>>>>>>>> associated. The alternative would be to require a custom
>>>>>>>>> ValueExtractor? This seems cumbersome and unnecessary.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Matt
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>> _______________________________________________
>>> 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/20170621/0fc263f4/attachment-0001.html 

From mbenson at apache.org  Wed Jun 21 08:36:30 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 21 Jun 2017 07:36:30 -0500
Subject: [bv-dev] @Past(orPresent=true) -> @PastOrPresent?
In-Reply-To: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>
References: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>
Message-ID: <CAE9L6G2oN6ijS-5+HPeCujoZo0vTT5bVY_JiNbk3RVmKsNb0qQ@mail.gmail.com>

I can see the advantage of consistency (though this is establishing a
pattern to which we'd be expected to stick going forward). Also, removing
the additional annotation element does mean no #init() method for the
implementation, for whatever that's worth. I don't feel strongly about it,
but I don't really have any negative arguments.

Matt

On Jun 21, 2017 5:00 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> Hi all,
>
> A colleague of mine reviewing the BV 2.0 changes pointed out an
> inconsistency in the added/modified constraints.
>
> As per the community poll we have now @NegativeOrZero and
> @PositiveOrZero, whereas we still have the orPresent() option on @Past
> and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
> for the sake of consistency?
>
> Now one could argue that having only attributes (orPresent(),
> orZero()) is most consistent with other constraints such as
> @DigitalMin. But indeed the explicit annotations grew on me over time
> as they are a bit shorter to use and, more importantly, better to
> read.
>
> It's late in the game, but I feel inclined to extract @PastOrPresent
> and @FutureOrPresent. What do you think?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> 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/20170621/50c84eaa/attachment.html 

From emmanuel at hibernate.org  Wed Jun 21 13:00:15 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 21 Jun 2017 19:00:15 +0200
Subject: [bv-dev] @Past(orPresent=true) -> @PastOrPresent?
In-Reply-To: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>
References: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>
Message-ID: <3600398E-789E-4486-AE6B-F34CE8EC86AA@hibernate.org>

My argument against is that @Past / @Future could need additional options: like maybe past per year or month instead of instant time. I understand we do use the type structure to extract that information.
Is there potential options people can think of around time constraints?

For @Positive/@Negative, we decided there were none.

> On 21 Jun 2017, at 11:50, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi all,
> 
> A colleague of mine reviewing the BV 2.0 changes pointed out an
> inconsistency in the added/modified constraints.
> 
> As per the community poll we have now @NegativeOrZero and
> @PositiveOrZero, whereas we still have the orPresent() option on @Past
> and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
> for the sake of consistency?
> 
> Now one could argue that having only attributes (orPresent(),
> orZero()) is most consistent with other constraints such as
> @DigitalMin. But indeed the explicit annotations grew on me over time
> as they are a bit shorter to use and, more importantly, better to
> read.
> 
> It's late in the game, but I feel inclined to extract @PastOrPresent
> and @FutureOrPresent. What do you think?
> 
> Thanks,
> 
> --Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev



From gunnar at hibernate.org  Wed Jun 21 13:33:32 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 21 Jun 2017 19:33:32 +0200
Subject: [bv-dev] @Past(orPresent=true) -> @PastOrPresent?
In-Reply-To: <3600398E-789E-4486-AE6B-F34CE8EC86AA@hibernate.org>
References: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>
	<3600398E-789E-4486-AE6B-F34CE8EC86AA@hibernate.org>
Message-ID: <CADGJaX-A8y8RUzcUuPCufdWfZHHp1qqAaz7X3iBXAVxC8rBp4A@mail.gmail.com>

Just from - very quickly - thinking, no options are coming to my mind.

Note that we're about to push the Proposed Final Draft (CR1) with the
separate annotations in a bit. We still an re-consider until the Final
if something strongly speaks against it, but it seemed like the more
likely option to me and the PFD should be out today so it's up online
by the end of the week.

I wish the question would have come up earlier so it wouldn't be such
a rush, but well...


2017-06-21 19:00 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> My argument against is that @Past / @Future could need additional options: like maybe past per year or month instead of instant time. I understand we do use the type structure to extract that information.
> Is there potential options people can think of around time constraints?
>
> For @Positive/@Negative, we decided there were none.
>
>> On 21 Jun 2017, at 11:50, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi all,
>>
>> A colleague of mine reviewing the BV 2.0 changes pointed out an
>> inconsistency in the added/modified constraints.
>>
>> As per the community poll we have now @NegativeOrZero and
>> @PositiveOrZero, whereas we still have the orPresent() option on @Past
>> and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
>> for the sake of consistency?
>>
>> Now one could argue that having only attributes (orPresent(),
>> orZero()) is most consistent with other constraints such as
>> @DigitalMin. But indeed the explicit annotations grew on me over time
>> as they are a bit shorter to use and, more importantly, better to
>> read.
>>
>> It's late in the game, but I feel inclined to extract @PastOrPresent
>> and @FutureOrPresent. What do you think?
>>
>> Thanks,
>>
>> --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 moltenma at gmail.com  Thu Jun 22 03:15:22 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Thu, 22 Jun 2017 09:15:22 +0200
Subject: [bv-dev] @Past(orPresent=true) -> @PastOrPresent?
In-Reply-To: <CADGJaX-A8y8RUzcUuPCufdWfZHHp1qqAaz7X3iBXAVxC8rBp4A@mail.gmail.com>
References: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>
	<3600398E-789E-4486-AE6B-F34CE8EC86AA@hibernate.org>
	<CADGJaX-A8y8RUzcUuPCufdWfZHHp1qqAaz7X3iBXAVxC8rBp4A@mail.gmail.com>
Message-ID: <CANUPYM2WuFeBuFbyF60MOqed6XpZMTwNJK+BDoKOVxVYSQ9uVA@mail.gmail.com>

>
>  as they are a bit shorter to use and, more importantly, better to
>  read.


I agree.

 It's late in the game, but I feel inclined to extract @PastOrPresent
>  and @FutureOrPresent. What do you think?



Ok for me.



On Wed, Jun 21, 2017 at 7:33 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Just from - very quickly - thinking, no options are coming to my mind.
>
> Note that we're about to push the Proposed Final Draft (CR1) with the
> separate annotations in a bit. We still an re-consider until the Final
> if something strongly speaks against it, but it seemed like the more
> likely option to me and the PFD should be out today so it's up online
> by the end of the week.
>
> I wish the question would have come up earlier so it wouldn't be such
> a rush, but well...
>
>
> 2017-06-21 19:00 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > My argument against is that @Past / @Future could need additional
> options: like maybe past per year or month instead of instant time. I
> understand we do use the type structure to extract that information.
> > Is there potential options people can think of around time constraints?
> >
> > For @Positive/@Negative, we decided there were none.
> >
> >> On 21 Jun 2017, at 11:50, Gunnar Morling <gunnar at hibernate.org> wrote:
> >>
> >> Hi all,
> >>
> >> A colleague of mine reviewing the BV 2.0 changes pointed out an
> >> inconsistency in the added/modified constraints.
> >>
> >> As per the community poll we have now @NegativeOrZero and
> >> @PositiveOrZero, whereas we still have the orPresent() option on @Past
> >> and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
> >> for the sake of consistency?
> >>
> >> Now one could argue that having only attributes (orPresent(),
> >> orZero()) is most consistent with other constraints such as
> >> @DigitalMin. But indeed the explicit annotations grew on me over time
> >> as they are a bit shorter to use and, more importantly, better to
> >> read.
> >>
> >> It's late in the game, but I feel inclined to extract @PastOrPresent
> >> and @FutureOrPresent. What do you think?
> >>
> >> Thanks,
> >>
> >> --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
> _______________________________________________
> 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/20170622/14feb190/attachment.html 

From gunnar at hibernate.org  Thu Jun 22 04:52:13 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 22 Jun 2017 10:52:13 +0200
Subject: [bv-dev] Proposed Final Draft submitted
Message-ID: <CADGJaX9v6jzw-O+Fo3b_BTgkJ66=1P+oyz=7tWRfd=6oRnCa-w@mail.gmail.com>

Hi all,

As discussed, I've submitted the Proposed Final Draft (2.0.0.CR1 in
our versioning scheme) to the JCP last night.

You can find the full spec and diffs here on our website:

* http://beanvalidation.org/2.0/spec/2.0.0.cr1/
* http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-1.1/
* http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-2.0-beta2/

As always, let's wait with spreading the news on Twitter etc. until
it's published on jcp.org, which should be the case within the next
few days.

Currently we're working on updating the RI and the TCK to align with
CR1, corresponding releases should be out next week.

As we're in the CR phase ("candidate release") now, the work should be
considered feature-complete. Forward going, changes should essentially
be limited to critical adjustments, bug fixes, clarifications,
cosmetic things like formatting, JavaDoc, and things like that.

My current thinking is to release a CR2 (just on beanvalidation.org)
mid next week, with any improvements we've done by then.

The submission for the Final Approval Ballot needs to be done by July
5th. I.e. we have two weeks remaining to hone and polish the spec.
Again, please use this time for reviewing and proof-reading -- any
feedback you may have is much appreciated.

If you see any open issues or have any concerns or questions about the
path going forward, please let me know.

Thanks,

--Gunnar

From otaviopolianasantana at gmail.com  Thu Jun 22 07:04:57 2017
From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Thu, 22 Jun 2017 08:04:57 -0300
Subject: [bv-dev] @Past(orPresent=true) -> @PastOrPresent?
In-Reply-To: <CANUPYM2WuFeBuFbyF60MOqed6XpZMTwNJK+BDoKOVxVYSQ9uVA@mail.gmail.com>
References: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>
	<3600398E-789E-4486-AE6B-F34CE8EC86AA@hibernate.org>
	<CADGJaX-A8y8RUzcUuPCufdWfZHHp1qqAaz7X3iBXAVxC8rBp4A@mail.gmail.com>
	<CANUPYM2WuFeBuFbyF60MOqed6XpZMTwNJK+BDoKOVxVYSQ9uVA@mail.gmail.com>
Message-ID: <CAPc8kR3E2sCgvGr0_=haBooRR7pmLx2FKKtGV-1iyB_qt=EXxA@mail.gmail.com>

I'm not a big fan of this option.
I mean, who can we define the present?
On the same API that will easy:

   - YearMonth
   <https://docs.oracle.com/javase/8/docs/api/java/time/YearMonth.html>
   - Year <https://docs.oracle.com/javase/8/docs/api/java/time/Year.html>
   - LocalDate
   <https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html>


But the API that cares about milliseconds? that will complicate, so we need
to define a delta.


   - LocalDateTime
   <https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html>
   - LocalTime
   <https://docs.oracle.com/javase/8/docs/api/java/time/LocalTime.html>
   - Instant
   <https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html>


On Thu, Jun 22, 2017 at 4:15 AM, Marco Molteni <moltenma at gmail.com> wrote:

>  as they are a bit shorter to use and, more importantly, better to
>>  read.
>
>
> I agree.
>
>  It's late in the game, but I feel inclined to extract @PastOrPresent
>>  and @FutureOrPresent. What do you think?
>
>
>
> Ok for me.
>
>
>
>
> On Wed, Jun 21, 2017 at 7:33 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Just from - very quickly - thinking, no options are coming to my mind.
>>
>> Note that we're about to push the Proposed Final Draft (CR1) with the
>> separate annotations in a bit. We still an re-consider until the Final
>> if something strongly speaks against it, but it seemed like the more
>> likely option to me and the PFD should be out today so it's up online
>> by the end of the week.
>>
>> I wish the question would have come up earlier so it wouldn't be such
>> a rush, but well...
>>
>>
>> 2017-06-21 19:00 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> > My argument against is that @Past / @Future could need additional
>> options: like maybe past per year or month instead of instant time. I
>> understand we do use the type structure to extract that information.
>> > Is there potential options people can think of around time constraints?
>> >
>> > For @Positive/@Negative, we decided there were none.
>> >
>> >> On 21 Jun 2017, at 11:50, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> A colleague of mine reviewing the BV 2.0 changes pointed out an
>> >> inconsistency in the added/modified constraints.
>> >>
>> >> As per the community poll we have now @NegativeOrZero and
>> >> @PositiveOrZero, whereas we still have the orPresent() option on @Past
>> >> and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
>> >> for the sake of consistency?
>> >>
>> >> Now one could argue that having only attributes (orPresent(),
>> >> orZero()) is most consistent with other constraints such as
>> >> @DigitalMin. But indeed the explicit annotations grew on me over time
>> >> as they are a bit shorter to use and, more importantly, better to
>> >> read.
>> >>
>> >> It's late in the game, but I feel inclined to extract @PastOrPresent
>> >> and @FutureOrPresent. What do you think?
>> >>
>> >> Thanks,
>> >>
>> >> --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
>> _______________________________________________
>> 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
>



-- 
Ot?vio Gon?alves de Santana


twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170622/6624e518/attachment.html 

From gunnar at hibernate.org  Tue Jun 27 03:48:13 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 27 Jun 2017 09:48:13 +0200
Subject: [bv-dev] @Past(orPresent=true) -> @PastOrPresent?
In-Reply-To: <CAPc8kR3E2sCgvGr0_=haBooRR7pmLx2FKKtGV-1iyB_qt=EXxA@mail.gmail.com>
References: <CADGJaX_63ebjfthNA98tOh7kygh+w+fH7zP_krjagmfau+RJQg@mail.gmail.com>
	<3600398E-789E-4486-AE6B-F34CE8EC86AA@hibernate.org>
	<CADGJaX-A8y8RUzcUuPCufdWfZHHp1qqAaz7X3iBXAVxC8rBp4A@mail.gmail.com>
	<CANUPYM2WuFeBuFbyF60MOqed6XpZMTwNJK+BDoKOVxVYSQ9uVA@mail.gmail.com>
	<CAPc8kR3E2sCgvGr0_=haBooRR7pmLx2FKKtGV-1iyB_qt=EXxA@mail.gmail.com>
Message-ID: <CADGJaX_74phdpunS-Y=AiAMuN+=1biMBbzO34EvFV-oaV21dpg@mail.gmail.com>

Hey Otavio,

Adding attributes for defining some kind of allowed range could be
done either way in the future, no matter whether it's
@Future(orPresent=) or @FutureOrPresent.

Could you describe in a bit more detail what you have in mind?

Thanks,

--Gunnar



2017-06-22 13:04 GMT+02:00 Ot?vio Gon?alves de Santana
<otaviopolianasantana at gmail.com>:
> I'm not a big fan of this option.
> I mean, who can we define the present?
> On the same API that will easy:
>
> YearMonth
> Year
> LocalDate
>
>
> But the API that cares about milliseconds? that will complicate, so we need
> to define a delta.
>
> LocalDateTime
> LocalTime
> Instant
>
>
> On Thu, Jun 22, 2017 at 4:15 AM, Marco Molteni <moltenma at gmail.com> wrote:
>>>
>>>  as they are a bit shorter to use and, more importantly, better to
>>>  read.
>>
>>
>> I agree.
>>
>>>  It's late in the game, but I feel inclined to extract @PastOrPresent
>>>  and @FutureOrPresent. What do you think?
>>
>>
>>
>> Ok for me.
>>
>>
>>
>>
>> On Wed, Jun 21, 2017 at 7:33 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> Just from - very quickly - thinking, no options are coming to my mind.
>>>
>>> Note that we're about to push the Proposed Final Draft (CR1) with the
>>> separate annotations in a bit. We still an re-consider until the Final
>>> if something strongly speaks against it, but it seemed like the more
>>> likely option to me and the PFD should be out today so it's up online
>>> by the end of the week.
>>>
>>> I wish the question would have come up earlier so it wouldn't be such
>>> a rush, but well...
>>>
>>>
>>> 2017-06-21 19:00 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> > My argument against is that @Past / @Future could need additional
>>> > options: like maybe past per year or month instead of instant time. I
>>> > understand we do use the type structure to extract that information.
>>> > Is there potential options people can think of around time constraints?
>>> >
>>> > For @Positive/@Negative, we decided there were none.
>>> >
>>> >> On 21 Jun 2017, at 11:50, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> A colleague of mine reviewing the BV 2.0 changes pointed out an
>>> >> inconsistency in the added/modified constraints.
>>> >>
>>> >> As per the community poll we have now @NegativeOrZero and
>>> >> @PositiveOrZero, whereas we still have the orPresent() option on @Past
>>> >> and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
>>> >> for the sake of consistency?
>>> >>
>>> >> Now one could argue that having only attributes (orPresent(),
>>> >> orZero()) is most consistent with other constraints such as
>>> >> @DigitalMin. But indeed the explicit annotations grew on me over time
>>> >> as they are a bit shorter to use and, more importantly, better to
>>> >> read.
>>> >>
>>> >> It's late in the game, but I feel inclined to extract @PastOrPresent
>>> >> and @FutureOrPresent. What do you think?
>>> >>
>>> >> Thanks,
>>> >>
>>> >> --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
>>> _______________________________________________
>>> 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
>
>
>
>
> --
> Ot?vio Gon?alves de Santana
>
>
> twitter: http://twitter.com/otaviojava
> site:     http://about.me/otaviojava
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From gunnar at hibernate.org  Tue Jun 27 05:47:57 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 27 Jun 2017 11:47:57 +0200
Subject: [bv-dev] Proposed Final Draft submitted
In-Reply-To: <CADGJaX9v6jzw-O+Fo3b_BTgkJ66=1P+oyz=7tWRfd=6oRnCa-w@mail.gmail.com>
References: <CADGJaX9v6jzw-O+Fo3b_BTgkJ66=1P+oyz=7tWRfd=6oRnCa-w@mail.gmail.com>
Message-ID: <CADGJaX8jEqg2jHLRGNiF1o5MOPpZewZP=dOPytkKPty2jbU_Ug@mail.gmail.com>

Hi all,

The Proposed Final Draft has been published:

    http://beanvalidation.org/news/2017/06/26/bean-validation-2-0-proposed-final-draft-released/

Cheers,

--Gunnar


2017-06-22 10:52 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> Hi all,
>
> As discussed, I've submitted the Proposed Final Draft (2.0.0.CR1 in
> our versioning scheme) to the JCP last night.
>
> You can find the full spec and diffs here on our website:
>
> * http://beanvalidation.org/2.0/spec/2.0.0.cr1/
> * http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-1.1/
> * http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-2.0-beta2/
>
> As always, let's wait with spreading the news on Twitter etc. until
> it's published on jcp.org, which should be the case within the next
> few days.
>
> Currently we're working on updating the RI and the TCK to align with
> CR1, corresponding releases should be out next week.
>
> As we're in the CR phase ("candidate release") now, the work should be
> considered feature-complete. Forward going, changes should essentially
> be limited to critical adjustments, bug fixes, clarifications,
> cosmetic things like formatting, JavaDoc, and things like that.
>
> My current thinking is to release a CR2 (just on beanvalidation.org)
> mid next week, with any improvements we've done by then.
>
> The submission for the Final Approval Ballot needs to be done by July
> 5th. I.e. we have two weeks remaining to hone and polish the spec.
> Again, please use this time for reviewing and proof-reading -- any
> feedback you may have is much appreciated.
>
> If you see any open issues or have any concerns or questions about the
> path going forward, please let me know.
>
> Thanks,
>
> --Gunnar

From christian at kaltepoth.de  Thu Jun 29 00:52:49 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Thu, 29 Jun 2017 06:52:49 +0200
Subject: [bv-dev] Proposed Final Draft submitted
In-Reply-To: <CADGJaX8jEqg2jHLRGNiF1o5MOPpZewZP=dOPytkKPty2jbU_Ug@mail.gmail.com>
References: <CADGJaX9v6jzw-O+Fo3b_BTgkJ66=1P+oyz=7tWRfd=6oRnCa-w@mail.gmail.com>
	<CADGJaX8jEqg2jHLRGNiF1o5MOPpZewZP=dOPytkKPty2jbU_Ug@mail.gmail.com>
Message-ID: <CAEXeC6xKJHxeDqFCvrvp9EGMna+CRnRm_qQDGADTRL=ygjmxGg@mail.gmail.com>

Great news! Thanks Gunnar!

2017-06-27 11:47 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> Hi all,
>
> The Proposed Final Draft has been published:
>
>     http://beanvalidation.org/news/2017/06/26/bean-
> validation-2-0-proposed-final-draft-released/
>
> Cheers,
>
> --Gunnar
>
>
> 2017-06-22 10:52 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> > Hi all,
> >
> > As discussed, I've submitted the Proposed Final Draft (2.0.0.CR1 in
> > our versioning scheme) to the JCP last night.
> >
> > You can find the full spec and diffs here on our website:
> >
> > * http://beanvalidation.org/2.0/spec/2.0.0.cr1/
> > * http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-1.1/
> > * http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-2.0-beta2/
> >
> > As always, let's wait with spreading the news on Twitter etc. until
> > it's published on jcp.org, which should be the case within the next
> > few days.
> >
> > Currently we're working on updating the RI and the TCK to align with
> > CR1, corresponding releases should be out next week.
> >
> > As we're in the CR phase ("candidate release") now, the work should be
> > considered feature-complete. Forward going, changes should essentially
> > be limited to critical adjustments, bug fixes, clarifications,
> > cosmetic things like formatting, JavaDoc, and things like that.
> >
> > My current thinking is to release a CR2 (just on beanvalidation.org)
> > mid next week, with any improvements we've done by then.
> >
> > The submission for the Final Approval Ballot needs to be done by July
> > 5th. I.e. we have two weeks remaining to hone and polish the spec.
> > Again, please use this time for reviewing and proof-reading -- any
> > feedback you may have is much appreciated.
> >
> > If you see any open issues or have any concerns or questions about the
> > path going forward, please let me know.
> >
> > Thanks,
> >
> > --Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170629/6543dc8f/attachment-0001.html