From gunnar at hibernate.org  Thu Feb  2 09:14:07 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 2 Feb 2017 15:14:07 +0100
Subject: [bv-dev] JSR 380 Contributor Nominations
Message-ID: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>

Hi,

For the sake of transparency: There have been several nominations to
become a "Contributor" of this JSR. As per the JCP, "Contributors are
people who are NOT on the Expert Group of the JSR but whom you wish to
publicly recognize for their work on the JSR".

I'm very willing to formally recognize every contributor, but I think
at first there should be some actual contribution. The bar can be very
low, e.g. start a discussion on this mailing list on a topic you'd
like to see addressed in BV 2.0 and I'd consider that worthy to be
listed (ongoing contributions are even better of course). Or e.g.
provide feedback on the upcoming drafts.

So my recommendation for such incoming nominations is to do exactly
that: come to this mailing list, get involved by any means and you are
a true contributor.

--Gunnar

From misterm at gmail.com  Thu Feb  2 10:58:36 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Thu, 2 Feb 2017 13:58:36 -0200
Subject: [bv-dev] JSR 380 Contributor Nominations
In-Reply-To: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>
References: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>
Message-ID: <CAAWA2oX2fBq21=w2Qn2epmGMmerFByps60pJa+5XOOt4DQSV=g@mail.gmail.com>

+1

Regards,
Michael

On Thu, Feb 2, 2017 at 12:14 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> For the sake of transparency: There have been several nominations to
> become a "Contributor" of this JSR. As per the JCP, "Contributors are
> people who are NOT on the Expert Group of the JSR but whom you wish to
> publicly recognize for their work on the JSR".
>
> I'm very willing to formally recognize every contributor, but I think
> at first there should be some actual contribution. The bar can be very
> low, e.g. start a discussion on this mailing list on a topic you'd
> like to see addressed in BV 2.0 and I'd consider that worthy to be
> listed (ongoing contributions are even better of course). Or e.g.
> provide feedback on the upcoming drafts.
>
> So my recommendation for such incoming nominations is to do exactly
> that: come to this mailing list, get involved by any means and you are
> a true contributor.
>
> --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/20170202/cf5f60cd/attachment.html 

From otaviopolianasantana at gmail.com  Thu Feb  2 11:01:30 2017
From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Thu, 2 Feb 2017 14:01:30 -0200
Subject: [bv-dev] JSR 380 Contributor Nominations
In-Reply-To: <CAAWA2oX2fBq21=w2Qn2epmGMmerFByps60pJa+5XOOt4DQSV=g@mail.gmail.com>
References: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>
	<CAAWA2oX2fBq21=w2Qn2epmGMmerFByps60pJa+5XOOt4DQSV=g@mail.gmail.com>
Message-ID: <CAPc8kR3Q9rv1xzMdVq0vPG458MUbWz6qpYOF14iJyhcjyh6vkQ@mail.gmail.com>

Agree

On Feb 2, 2017 13:58, "Michael Nascimento" <misterm at gmail.com> wrote:

> +1
>
> Regards,
> Michael
>
> On Thu, Feb 2, 2017 at 12:14 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> For the sake of transparency: There have been several nominations to
>> become a "Contributor" of this JSR. As per the JCP, "Contributors are
>> people who are NOT on the Expert Group of the JSR but whom you wish to
>> publicly recognize for their work on the JSR".
>>
>> I'm very willing to formally recognize every contributor, but I think
>> at first there should be some actual contribution. The bar can be very
>> low, e.g. start a discussion on this mailing list on a topic you'd
>> like to see addressed in BV 2.0 and I'd consider that worthy to be
>> listed (ongoing contributions are even better of course). Or e.g.
>> provide feedback on the upcoming drafts.
>>
>> So my recommendation for such incoming nominations is to do exactly
>> that: come to this mailing list, get involved by any means and you are
>> a true contributor.
>>
>> --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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170202/955e6673/attachment.html 

From hendrik.ebbers at me.com  Thu Feb  2 11:49:24 2017
From: hendrik.ebbers at me.com (Hendrik Ebbers)
Date: Thu, 02 Feb 2017 17:49:24 +0100
Subject: [bv-dev] JSR 380 Contributor Nominations
In-Reply-To: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>
References: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>
Message-ID: <5F578726-CA39-4722-8411-A37E1B695DDD@me.com>

+1


> Am 02.02.2017 um 15:14 schrieb Gunnar Morling <gunnar at hibernate.org>:
> 
> Hi,
> 
> For the sake of transparency: There have been several nominations to
> become a "Contributor" of this JSR. As per the JCP, "Contributors are
> people who are NOT on the Expert Group of the JSR but whom you wish to
> publicly recognize for their work on the JSR".
> 
> I'm very willing to formally recognize every contributor, but I think
> at first there should be some actual contribution. The bar can be very
> low, e.g. start a discussion on this mailing list on a topic you'd
> like to see addressed in BV 2.0 and I'd consider that worthy to be
> listed (ongoing contributions are even better of course). Or e.g.
> provide feedback on the upcoming drafts.
> 
> So my recommendation for such incoming nominations is to do exactly
> that: come to this mailing list, get involved by any means and you are
> a true contributor.
> 
> --Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From gunnar at hibernate.org  Thu Feb  2 12:33:31 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 2 Feb 2017 18:33:31 +0100
Subject: [bv-dev] Someone up for an XML-related task?
Message-ID: <CADGJaX957t_jDNN-17d19XZ7OCimfNa8W8NHG_zorP5SjQ45bQ@mail.gmail.com>

Hey,

One of the loose ends around container value extraction is the
XML-based definition of type-argument constraints and cascaded type
parameters (i.e. XML counterparts to List<@Email String> emails or
Map<@Valid CustomerType, Customer> customers).

Is there any XSD aficionado out there who would like to give this a
shot and come up with a first proposal for the new schema? It's an
important task and any help with it would be more than welcome :)

Thanks,

--Gunnar

From christian at kaltepoth.de  Thu Feb  2 12:58:48 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Thu, 2 Feb 2017 18:58:48 +0100
Subject: [bv-dev] JSR 380 Contributor Nominations
In-Reply-To: <5F578726-CA39-4722-8411-A37E1B695DDD@me.com>
References: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>
	<5F578726-CA39-4722-8411-A37E1B695DDD@me.com>
Message-ID: <CAEXeC6zmqoYayS1kb25E4j63WNs-O+URs0+gLVupvUmgV=fE1A@mail.gmail.com>

+1! Sounds good!

2017-02-02 17:49 GMT+01:00 Hendrik Ebbers <hendrik.ebbers at me.com>:

> +1
>
>
> > Am 02.02.2017 um 15:14 schrieb Gunnar Morling <gunnar at hibernate.org>:
> >
> > Hi,
> >
> > For the sake of transparency: There have been several nominations to
> > become a "Contributor" of this JSR. As per the JCP, "Contributors are
> > people who are NOT on the Expert Group of the JSR but whom you wish to
> > publicly recognize for their work on the JSR".
> >
> > I'm very willing to formally recognize every contributor, but I think
> > at first there should be some actual contribution. The bar can be very
> > low, e.g. start a discussion on this mailing list on a topic you'd
> > like to see addressed in BV 2.0 and I'd consider that worthy to be
> > listed (ongoing contributions are even better of course). Or e.g.
> > provide feedback on the upcoming drafts.
> >
> > So my recommendation for such incoming nominations is to do exactly
> > that: come to this mailing list, get involved by any means and you are
> > a true contributor.
> >
> > --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
>



-- 
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/20170202/f3d5495d/attachment.html 

From moltenma at gmail.com  Thu Feb  2 17:57:27 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Thu, 2 Feb 2017 23:57:27 +0100
Subject: [bv-dev] JSR 380 Contributor Nominations
In-Reply-To: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>
References: <CADGJaX9CK1xA_qa0wmn6AdYQhpcmoZ_PSomqPHUXaB4suQM9Xw@mail.gmail.com>
Message-ID: <4FDDE842-5CBE-4733-B28B-84AE249D86AF@gmail.com>

Agree, +1

> Am 02.02.2017 um 15:14 schrieb Gunnar Morling <gunnar at hibernate.org>:
> 
> Hi,
> 
> For the sake of transparency: There have been several nominations to
> become a "Contributor" of this JSR. As per the JCP, "Contributors are
> people who are NOT on the Expert Group of the JSR but whom you wish to
> publicly recognize for their work on the JSR".
> 
> I'm very willing to formally recognize every contributor, but I think
> at first there should be some actual contribution. The bar can be very
> low, e.g. start a discussion on this mailing list on a topic you'd
> like to see addressed in BV 2.0 and I'd consider that worthy to be
> listed (ongoing contributions are even better of course). Or e.g.
> provide feedback on the upcoming drafts.
> 
> So my recommendation for such incoming nominations is to do exactly
> that: come to this mailing list, get involved by any means and you are
> a true contributor.
> 
> --Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From thoroughsoft at gmail.com  Mon Feb  6 17:35:34 2017
From: thoroughsoft at gmail.com (Anders Persson)
Date: Mon, 6 Feb 2017 23:35:34 +0100
Subject: [bv-dev] Fwd: Limitations found in previous bean validation
In-Reply-To: <CAEOrrnC3TGOy+zYqr2nZ=4_1yUPxB-JbegDiW44eGZpMGEGf+w@mail.gmail.com>
References: <CAEOrrnC3TGOy+zYqr2nZ=4_1yUPxB-JbegDiW44eGZpMGEGf+w@mail.gmail.com>
Message-ID: <CAEOrrnBp1pW0+q1ozJg3jfj6W=aC04uuTS_NufgAvsGTNw6-Gw@mail.gmail.com>

Hi all,
So a couple of months back I had a bean structure that I wanted to validate.
My selection was to use the validation framework.
I could after a while see that the framework specification, and hence the
implementations, fell short in several areas so my ideas below are based on
a live project.

1) Sometimes the contents of one bean depends on the contents of another
bean. The current specification does not in any way allow navigating the
bean tree despite this information being available internally of the
implementations. Also accessing the bean instances to get hold of the data
is not supported. The closest to a solution here was the Hibernate
implementation which did add a proprietary interface to extract the data
using PropertyNode. There is however a somewhat strange limitation in the
Hibernate implementation in that navigating the bean path does not allow
you to access the root bean, only the first children under the bean. This
means if the relevant data is located in another branch under the root node
there is no way to gain access to the data.
Solution: Allow full navigation up and down the bean structure and allow
accessing the bean instance to get hold of the data. A framework should not
impose limitations to what validation a user wants to do. This means make
the getValue method of Hibernate PropertyNode part of the standard and add
a getParent() to, for instance, Path.BeanNode to allow moving up the path.

2) Sometimes the bean structure can consist of lists with a large number of
elements. The current solution with index number makes it very cumbersome
to match a failed validation to whatever source of data you have (database,
xml file, input from webservice etc). In many cases an element (bean)
contains some data which can be considered as a "primary key" which makes
it easy to identify in the input data. To handle this I created a StringId
interface that the beans would implement and I then used this as output
when parsing the validation result. This however requires me to implement a
formatter for something that I think should be supported out of the box by
the validation specification.
Solution: Create an interface (of annotation, I have no strong feeling
about the actual implementation) that can be used to identify elements in a
list.

3) Sometimes the validation is situation dependent, for instance, the
expected bean contents depend on where the data is coming from or at what
point in time in the business process it is being validated. It would be
desirable to easily pass in a settings object in the validation method.
Solution: Extend ConstraintValidatorContext to allow passing user data or
extend the validation method to take an arbitrary Object given by the user.

I hope that I have been able to make my ideas clear and that there are not
too many errors in what I have written. It has been a while since I wrote
this code and I have since changed company so I can't check and verify that
I have gotten all details right.

Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170206/56946a3f/attachment.html 

From gunnar at hibernate.org  Tue Feb  7 03:01:53 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 7 Feb 2017 09:01:53 +0100
Subject: [bv-dev] Fwd: Limitations found in previous bean validation
In-Reply-To: <CAEOrrnBp1pW0+q1ozJg3jfj6W=aC04uuTS_NufgAvsGTNw6-Gw@mail.gmail.com>
References: <CAEOrrnC3TGOy+zYqr2nZ=4_1yUPxB-JbegDiW44eGZpMGEGf+w@mail.gmail.com>
	<CAEOrrnBp1pW0+q1ozJg3jfj6W=aC04uuTS_NufgAvsGTNw6-Gw@mail.gmail.com>
Message-ID: <CADGJaX9AUP+JH=wtEeGU8m_cHYuzwVEr0D-jqEMCQDL65nB6pQ@mail.gmail.com>

Hi Anders,

Thanks a lot for getting in touch and sharing your experiences and suggestions.

Some questions below inline.

--Gunnar

2017-02-06 23:35 GMT+01:00 Anders Persson <thoroughsoft at gmail.com>:
> Hi all,
> So a couple of months back I had a bean structure that I wanted to validate.
> My selection was to use the validation framework.
> I could after a while see that the framework specification, and hence the
> implementations, fell short in several areas so my ideas below are based on
> a live project.
>
> 1) Sometimes the contents of one bean depends on the contents of another
> bean. The current specification does not in any way allow navigating the
> bean tree despite this information being available internally of the
> implementations. Also accessing the bean instances to get hold of the data
> is not supported. The closest to a solution here was the Hibernate
> implementation which did add a proprietary interface to extract the data
> using PropertyNode. There is however a somewhat strange limitation in the
> Hibernate implementation in that navigating the bean path does not allow you
> to access the root bean, only the first children under the bean. This means
> if the relevant data is located in another branch under the root node there
> is no way to gain access to the data.
> Solution: Allow full navigation up and down the bean structure and allow
> accessing the bean instance to get hold of the data. A framework should not
> impose limitations to what validation a user wants to do. This means make
> the getValue method of Hibernate PropertyNode part of the standard and add a
> getParent() to, for instance, Path.BeanNode to allow moving up the path.

Can you give an example/use case for 1)? Is it that validation of bean
A depends on the state of a bean B referenced by A? If so, couldn't
you put this validation logic to B instead of A? And how do you
interact with PathNode here? Discussing a specific example would help
to grasp the full picture.

>
> 2) Sometimes the bean structure can consist of lists with a large number of
> elements. The current solution with index number makes it very cumbersome to
> match a failed validation to whatever source of data you have (database, xml
> file, input from webservice etc). In many cases an element (bean) contains
> some data which can be considered as a "primary key" which makes it easy to
> identify in the input data. To handle this I created a StringId interface
> that the beans would implement and I then used this as output when parsing
> the validation result. This however requires me to implement a formatter for
> something that I think should be supported out of the box by the validation
> specification.
> Solution: Create an interface (of annotation, I have no strong feeling about
> the actual implementation) that can be used to identify elements in a list.

Interesting one. Can you elaborate a bit on how you envision this
interface to look like and how it would be used?

>
> 3) Sometimes the validation is situation dependent, for instance, the
> expected bean contents depend on where the data is coming from or at what
> point in time in the business process it is being validated. It would be
> desirable to easily pass in a settings object in the validation method.
> Solution: Extend ConstraintValidatorContext to allow passing user data or
> extend the validation method to take an arbitrary Object given by the user.

Do you want to apply different constraints in different "situations"?
If so, validation groups should be helpful.

If you want one constraint to behave situation-specific (not sure
whether it's a good idea), there is a solution if you work with a
container such as CDI or Spring: Inject the required context using the
correct scope (e.g. request-scoped) into ConstraintValidator
implementations.

>
> I hope that I have been able to make my ideas clear and that there are not
> too many errors in what I have written. It has been a while since I wrote
> this code and I have since changed company so I can't check and verify that
> I have gotten all details right.
>
> Anders
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Wed Feb  8 05:57:18 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 8 Feb 2017 11:57:18 +0100
Subject: [bv-dev] Posted Early Draft 1 to the JCP
Message-ID: <CADGJaX8PVCP_D2bmyKDB2gZC4nGLh-sLGGSfFt+DtQxFcR1OBw@mail.gmail.com>

Hi all,

As discussed, I've cut an 2.0.0.Alpha1 release of the Bean Validation
API plus spec and send them to the JCP team for starting an Early
Draft review.

It may take a few days until it's up on jcp.org, so let's wait with
tweeting, blogging etc. until it's there at
https://www.jcp.org/en/jsr/detail?id=380.

We are in a good spot with the RI, too. So we should be able to do an
Alpha1 release of HV 6.0 at the same time as the EDR begins.

--Gunnar

From christian at kaltepoth.de  Wed Feb  8 07:18:39 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Wed, 8 Feb 2017 13:18:39 +0100
Subject: [bv-dev] Posted Early Draft 1 to the JCP
In-Reply-To: <CAEXeC6zBhoy0-8ei-v6t+gfgk=b36CbbQVb5k3S+Y0bKCsv8Bw@mail.gmail.com>
References: <CADGJaX8PVCP_D2bmyKDB2gZC4nGLh-sLGGSfFt+DtQxFcR1OBw@mail.gmail.com>
	<CAEXeC6w2XXi66k28oYFhzKrD7q=MnXx9Hkv450KPn8udqbFnSQ@mail.gmail.com>
	<CAEXeC6zBhoy0-8ei-v6t+gfgk=b36CbbQVb5k3S+Y0bKCsv8Bw@mail.gmail.com>
Message-ID: <CAEXeC6zQtwrYgQkRQww8K6_mydWa4_akT9-gjFWkEEE2egMEeQ@mail.gmail.com>

That's great news. Thanks everyone for the good work.

Am 08.02.2017 12:00 schrieb "Gunnar Morling" <gunnar at hibernate.org>:

Hi all,

As discussed, I've cut an 2.0.0.Alpha1 release of the Bean Validation
API plus spec and send them to the JCP team for starting an Early
Draft review.

It may take a few days until it's up on jcp.org, so let's wait with
tweeting, blogging etc. until it's there at
https://www.jcp.org/en/jsr/detail?id=380.

We are in a good spot with the RI, too. So we should be able to do an
Alpha1 release of HV 6.0 at the same time as the EDR begins.

--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/20170208/601462bb/attachment.html 

From otaviojava at java.net  Wed Feb  8 07:47:15 2017
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Wed, 8 Feb 2017 10:47:15 -0200
Subject: [bv-dev] Posted Early Draft 1 to the JCP
In-Reply-To: <CAEXeC6zQtwrYgQkRQww8K6_mydWa4_akT9-gjFWkEEE2egMEeQ@mail.gmail.com>
References: <CADGJaX8PVCP_D2bmyKDB2gZC4nGLh-sLGGSfFt+DtQxFcR1OBw@mail.gmail.com>
	<CAEXeC6w2XXi66k28oYFhzKrD7q=MnXx9Hkv450KPn8udqbFnSQ@mail.gmail.com>
	<CAEXeC6zBhoy0-8ei-v6t+gfgk=b36CbbQVb5k3S+Y0bKCsv8Bw@mail.gmail.com>
	<CAEXeC6zQtwrYgQkRQww8K6_mydWa4_akT9-gjFWkEEE2egMEeQ@mail.gmail.com>
Message-ID: <CAPc8kR2RYgZFO0m+e3z7vT+P6k5Xt1sZhhVB3YsC0vyCpFKJ2Q@mail.gmail.com>

Nice.

On Wed, Feb 8, 2017 at 10:18 AM, Christian Kaltepoth <christian at kaltepoth.de
> wrote:

> That's great news. Thanks everyone for the good work.
>
> Am 08.02.2017 12:00 schrieb "Gunnar Morling" <gunnar at hibernate.org>:
>
> Hi all,
>
> As discussed, I've cut an 2.0.0.Alpha1 release of the Bean Validation
> API plus spec and send them to the JCP team for starting an Early
> Draft review.
>
> It may take a few days until it's up on jcp.org, so let's wait with
> tweeting, blogging etc. until it's there at
> https://www.jcp.org/en/jsr/detail?id=380.
>
> We are in a good spot with the RI, too. So we should be able to do an
> Alpha1 release of HV 6.0 at the same time as the EDR begins.
>
> --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
>



-- 
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/20170208/1b294f89/attachment.html 

From gunnar at hibernate.org  Thu Feb  9 06:44:20 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 9 Feb 2017 12:44:20 +0100
Subject: [bv-dev] Two improvements related to exceptions
Message-ID: <CADGJaX_NHNNabM-R_9cSFijyFCDm2Mrs_q4+7ruGYaLyq5+qhw@mail.gmail.com>

Hi,

To take a break from the value extraction business, I've been working
on two small improvements related to the exception model:

* BVAL-559 [1]: This adds a new subtype of ValidationException,
NoProviderFoundException. This allows integrators to distinguish
between the case where no BV provider is around at all and the case
where a provider is there but fails to bootstrap (e.g. due to
misconfiguration in validation.xml). The use case for this is better
support for JPA's validation-mode "auto".
* BVAL-264 [2]: More useful exception message if a
ConstraintViolationException has been constructed from a set of
violations

The API and spec changes can be found at [3] and [4], respectively.
Please speak up if you have any remarks. If nothing comes up, I'll
merge both PRs mid next week.

Thanks for any feedback,

--Gunnar

[1] https://hibernate.atlassian.net/projects/BVAL/issues/BVAL-559
[2] https://hibernate.atlassian.net/projects/BVAL/issues/BVAL-264
[3] https://github.com/beanvalidation/beanvalidation-api/pull/82
[4] https://github.com/beanvalidation/beanvalidation-spec/pull/133

From moltenma at gmail.com  Tue Feb 14 02:58:10 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Tue, 14 Feb 2017 08:58:10 +0100
Subject: [bv-dev] Posted Early Draft 1 to the JCP
In-Reply-To: <CAPc8kR2RYgZFO0m+e3z7vT+P6k5Xt1sZhhVB3YsC0vyCpFKJ2Q@mail.gmail.com>
References: <CADGJaX8PVCP_D2bmyKDB2gZC4nGLh-sLGGSfFt+DtQxFcR1OBw@mail.gmail.com>
	<CAEXeC6w2XXi66k28oYFhzKrD7q=MnXx9Hkv450KPn8udqbFnSQ@mail.gmail.com>
	<CAEXeC6zBhoy0-8ei-v6t+gfgk=b36CbbQVb5k3S+Y0bKCsv8Bw@mail.gmail.com>
	<CAEXeC6zQtwrYgQkRQww8K6_mydWa4_akT9-gjFWkEEE2egMEeQ@mail.gmail.com>
	<CAPc8kR2RYgZFO0m+e3z7vT+P6k5Xt1sZhhVB3YsC0vyCpFKJ2Q@mail.gmail.com>
Message-ID: <CANUPYM1o5FfUZhQuWYUHfJehCxZgApmNmWgWMuHAQ40ezYwgOg@mail.gmail.com>

It's on jcp.org. Excellent work Gunnar, thanks!

On Wed, Feb 8, 2017 at 1:47 PM, Ot?vio Gon?alves de Santana <
otaviojava at java.net> wrote:

> Nice.
>
> On Wed, Feb 8, 2017 at 10:18 AM, Christian Kaltepoth <
> christian at kaltepoth.de> wrote:
>
>> That's great news. Thanks everyone for the good work.
>>
>> Am 08.02.2017 12:00 schrieb "Gunnar Morling" <gunnar at hibernate.org>:
>>
>> Hi all,
>>
>> As discussed, I've cut an 2.0.0.Alpha1 release of the Bean Validation
>> API plus spec and send them to the JCP team for starting an Early
>> Draft review.
>>
>> It may take a few days until it's up on jcp.org, so let's wait with
>> tweeting, blogging etc. until it's there at
>> https://www.jcp.org/en/jsr/detail?id=380.
>>
>> We are in a good spot with the RI, too. So we should be able to do an
>> Alpha1 release of HV 6.0 at the same time as the EDR begins.
>>
>> --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
>>
>
>
>
> --
> Ot?vio Gon?alves de Santana
>
>
> twitter: http://twitter.com/otaviojava
> site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
>
>
> _______________________________________________
> 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/20170214/6445179b/attachment-0001.html 

From gunnar at hibernate.org  Tue Feb 14 03:40:40 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 14 Feb 2017 09:40:40 +0100
Subject: [bv-dev] Posted Early Draft 1 to the JCP
In-Reply-To: <CANUPYM1o5FfUZhQuWYUHfJehCxZgApmNmWgWMuHAQ40ezYwgOg@mail.gmail.com>
References: <CADGJaX8PVCP_D2bmyKDB2gZC4nGLh-sLGGSfFt+DtQxFcR1OBw@mail.gmail.com>
	<CAEXeC6w2XXi66k28oYFhzKrD7q=MnXx9Hkv450KPn8udqbFnSQ@mail.gmail.com>
	<CAEXeC6zBhoy0-8ei-v6t+gfgk=b36CbbQVb5k3S+Y0bKCsv8Bw@mail.gmail.com>
	<CAEXeC6zQtwrYgQkRQww8K6_mydWa4_akT9-gjFWkEEE2egMEeQ@mail.gmail.com>
	<CAPc8kR2RYgZFO0m+e3z7vT+P6k5Xt1sZhhVB3YsC0vyCpFKJ2Q@mail.gmail.com>
	<CANUPYM1o5FfUZhQuWYUHfJehCxZgApmNmWgWMuHAQ40ezYwgOg@mail.gmail.com>
Message-ID: <CADGJaX-Fa4rc0-Ys4z+RNM9rt2c3qaVk2hYeYqYsMcV1_i57Sg@mail.gmail.com>

Ah, thanks, Marco! Apparently there was some technical issue, so it
took a bit to get it published.

Getting this (first) Early Draft out is a very important milestone,
thanks a lot to everyone involved for making it happen!

I hope we'll get some good community feedback on this, so please help
to spread the word on the ED, be it online or in your local
communities. I'll write a post for beanvalidation.org later today.

We've been focusing on the RI lately, so I think we can do an Alpha
release of HV 6.0, implementing Bean Validation 2.0.0.Alpha1, this
week, too, allowing people to play with type argument constraints and
the other new features.

Looking forward, it's the right time to discuss other things you think
should be in BV 2.0. I'm working on a proposal/change for the new
constraints as per the survey we did. Please speak up if you see
further issues we haven't discussed at all or have been discussing but
didn't reach closure yet.

--Gunnar


2017-02-14 8:58 GMT+01:00 Marco Molteni <moltenma at gmail.com>:
> It's on jcp.org. Excellent work Gunnar, thanks!
>
> On Wed, Feb 8, 2017 at 1:47 PM, Ot?vio Gon?alves de Santana
> <otaviojava at java.net> wrote:
>>
>> Nice.
>>
>> On Wed, Feb 8, 2017 at 10:18 AM, Christian Kaltepoth
>> <christian at kaltepoth.de> wrote:
>>>
>>> That's great news. Thanks everyone for the good work.
>>>
>>> Am 08.02.2017 12:00 schrieb "Gunnar Morling" <gunnar at hibernate.org>:
>>>
>>> Hi all,
>>>
>>> As discussed, I've cut an 2.0.0.Alpha1 release of the Bean Validation
>>> API plus spec and send them to the JCP team for starting an Early
>>> Draft review.
>>>
>>> It may take a few days until it's up on jcp.org, so let's wait with
>>> tweeting, blogging etc. until it's there at
>>> https://www.jcp.org/en/jsr/detail?id=380.
>>>
>>> We are in a good spot with the RI, too. So we should be able to do an
>>> Alpha1 release of HV 6.0 at the same time as the EDR begins.
>>>
>>> --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
>>
>>
>>
>>
>> --
>> 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
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From gunnar at hibernate.org  Thu Feb 16 13:03:24 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 16 Feb 2017 19:03:24 +0100
Subject: [bv-dev] First Alpha release of Bean Validation 2.0 RI
Message-ID: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>

Hi,

The first Alpha of the Bean Validation 2.0 reference implementation,
Hibernate Validator 6, is available now.

It implements the Early Draft 1, but also contains some more things
where we thought it'd be great to get some feedback first. E.g.
there's support for constraint definition using Lambda expressions.

Please check out the post on beanvalidation.org and the full
announcement on the Hibernate blog for all the details:

* http://beanvalidation.org/news/2017/02/16/first-alpha-of-bean-validation-2-0-reference-implementation/
* http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/

This release gives you the opportunity to play with the things we've
added so far, for instance you can experiment with custom value
extractors. Any feedback is welcome.

Thanks a lot to Guillaume for his hard work on this release!

--Gunnar

From misterm at gmail.com  Thu Feb 16 13:29:39 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Thu, 16 Feb 2017 16:29:39 -0200
Subject: [bv-dev] First Alpha release of Bean Validation 2.0 RI
In-Reply-To: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>
References: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>
Message-ID: <CAAWA2oXS8=0Et=Y_9CczTCafiVZ1b6UTA=jLXRFWkqT1xM_udA@mail.gmail.com>

Hi Gunnar,

Since Duration is really just seconds and milliseconds and any conversion
is always flat (in the sense it doesn't take into account daylight savings
time, for instance), I find it way less useful to support than Period and
arbitrary TemporalAmounts (such as
http://www.threeten.org/threeten-extra/apidocs/org/threeten/extra/Days.html
).

That's something we should probably focus on more because they are even
more fitting for use in business applications. Hopefully I won't disappear
for weeks anymore ;-)

Regards,
Michael

On Thu, Feb 16, 2017 at 4:03 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> The first Alpha of the Bean Validation 2.0 reference implementation,
> Hibernate Validator 6, is available now.
>
> It implements the Early Draft 1, but also contains some more things
> where we thought it'd be great to get some feedback first. E.g.
> there's support for constraint definition using Lambda expressions.
>
> Please check out the post on beanvalidation.org and the full
> announcement on the Hibernate blog for all the details:
>
> * http://beanvalidation.org/news/2017/02/16/first-alpha-
> of-bean-validation-2-0-reference-implementation/
> * http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/
>
> This release gives you the opportunity to play with the things we've
> added so far, for instance you can experiment with custom value
> extractors. Any feedback is welcome.
>
> Thanks a lot to Guillaume for his hard work on this release!
>
> --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/20170216/76c57b56/attachment.html 

From guillaume.smet at gmail.com  Thu Feb 16 13:48:25 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 16 Feb 2017 19:48:25 +0100
Subject: [bv-dev] First Alpha release of Bean Validation 2.0 RI
In-Reply-To: <CAAWA2oXS8=0Et=Y_9CczTCafiVZ1b6UTA=jLXRFWkqT1xM_udA@mail.gmail.com>
References: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>
	<CAAWA2oXS8=0Et=Y_9CczTCafiVZ1b6UTA=jLXRFWkqT1xM_udA@mail.gmail.com>
Message-ID: <CALt0+o_pM4Ms3o5W1g0s9DR4rsWcx5or3PJ5MWSkvB+59j944A@mail.gmail.com>

Hi Michael,

On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm at gmail.com>
wrote:
>
> Since Duration is really just seconds and milliseconds and any conversion
> is always flat (in the sense it doesn't take into account daylight savings
> time, for instance), I find it way less useful to support than Period and
> arbitrary TemporalAmounts (such as http://www.threeten.org/
> threeten-extra/apidocs/org/threeten/extra/Days.html ).
>

The first PR of Marko contained the Period support. The issue is that
Period is not comparable and there is no easy way to compare 2 periods so
we decided to not implement it for now. The typical issue we had is how do
you compare 1 month and 30 days.

As for supporting threeten-extra, it wouldn't be done in the spec anyway.
But we are open to consider it for HV (as we did for Joda a long time ago).
PR welcome!

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170216/59947b0e/attachment.html 

From misterm at gmail.com  Thu Feb 16 14:17:46 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Thu, 16 Feb 2017 17:17:46 -0200
Subject: [bv-dev] First Alpha release of Bean Validation 2.0 RI
In-Reply-To: <CALt0+o_pM4Ms3o5W1g0s9DR4rsWcx5or3PJ5MWSkvB+59j944A@mail.gmail.com>
References: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>
	<CAAWA2oXS8=0Et=Y_9CczTCafiVZ1b6UTA=jLXRFWkqT1xM_udA@mail.gmail.com>
	<CALt0+o_pM4Ms3o5W1g0s9DR4rsWcx5or3PJ5MWSkvB+59j944A@mail.gmail.com>
Message-ID: <CAAWA2oXYK+fmRuYUQA9VQFpysdzzarcG0LJNb1D+k+zrruAmMw@mail.gmail.com>

On Thu, Feb 16, 2017 at 4:48 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi Michael,
>
> On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm at gmail.com>
> wrote:
>>
>> Since Duration is really just seconds and milliseconds and any conversion
>> is always flat (in the sense it doesn't take into account daylight savings
>> time, for instance), I find it way less useful to support than Period and
>> arbitrary TemporalAmounts (such as http://www.threeten.org/thr
>> eeten-extra/apidocs/org/threeten/extra/Days.html ).
>>
>
> The first PR of Marko contained the Period support. The issue is that
> Period is not comparable and there is no easy way to compare 2 periods so
> we decided to not implement it for now. The typical issue we had is how do
> you compare 1 month and 30 days.
>

You don't compare, because they are not the same. The idea is that the
Period must be defined in terms of the units for which you defined its
boundaries.


> As for supporting threeten-extra, it wouldn't be done in the spec anyway.
>

You shouldn't support threeten-extra, but rather arbitrary TemporalAmounts.
Then threeten-extra just happen to be one of those. There must be something
like @ChronoUnitMax/@ChronoUnitMin such as:

@ChronoUnitMax(unit=DAYS, value=1)

As I said, I'm open to provide input, I was just surprised this support was
not discussed as part of the spec itself and prototyping work started right
way (in the less useful class for business applications, in my opinion).

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

From gunnar at hibernate.org  Fri Feb 17 03:11:47 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 17 Feb 2017 09:11:47 +0100
Subject: [bv-dev] First Alpha release of Bean Validation 2.0 RI
In-Reply-To: <CAAWA2oXYK+fmRuYUQA9VQFpysdzzarcG0LJNb1D+k+zrruAmMw@mail.gmail.com>
References: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>
	<CAAWA2oXS8=0Et=Y_9CczTCafiVZ1b6UTA=jLXRFWkqT1xM_udA@mail.gmail.com>
	<CALt0+o_pM4Ms3o5W1g0s9DR4rsWcx5or3PJ5MWSkvB+59j944A@mail.gmail.com>
	<CAAWA2oXYK+fmRuYUQA9VQFpysdzzarcG0LJNb1D+k+zrruAmMw@mail.gmail.com>
Message-ID: <CADGJaX8jYMZZkNCfqCUCavOW9UKJdcoudkLine2YFc8_xwLgyg@mail.gmail.com>

2017-02-16 20:17 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
> On Thu, Feb 16, 2017 at 4:48 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>>
>> Hi Michael,
>>
>> On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm at gmail.com>
>> wrote:
>>>
>>> Since Duration is really just seconds and milliseconds and any conversion
>>> is always flat (in the sense it doesn't take into account daylight savings
>>> time, for instance), I find it way less useful to support than Period and
>>> arbitrary TemporalAmounts (such as
>>> http://www.threeten.org/threeten-extra/apidocs/org/threeten/extra/Days.html
>>> ).
>>
>>
>> The first PR of Marko contained the Period support. The issue is that
>> Period is not comparable and there is no easy way to compare 2 periods so we
>> decided to not implement it for now. The typical issue we had is how do you
>> compare 1 month and 30 days.
>
>
> You don't compare, because they are not the same. The idea is that the
> Period must be defined in terms of the units for which you defined its
> boundaries.

I see. I'm wondering though how practical that will be. Will the
developer who puts the constraint always know the structure of the
Period set to the field (data set by the application user)?

>
>>
>> As for supporting threeten-extra, it wouldn't be done in the spec anyway.
>
>
> You shouldn't support threeten-extra, but rather arbitrary TemporalAmounts.
> Then threeten-extra just happen to be one of those. There must be something
> like @ChronoUnitMax/@ChronoUnitMin such as:
>
> @ChronoUnitMax(unit=DAYS, value=1)

How would that look like for a Period with several elements set, e.g.
"3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax
for each value of ChronoUnit (which are a lot)?

>
> As I said, I'm open to provide input, I was just surprised this support was
> not discussed as part of the spec itself and prototyping work started right
> way (in the less useful class for business applications, in my opinion).

We had a discussion of Duration et al. a while ago, but it petered
out. So we thought we'd add something to the RI to spark a new
discussion. Seems it worked :)


>
> 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  Mon Feb 20 10:54:29 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Feb 2017 16:54:29 +0100
Subject: [bv-dev] Value extraction open issue #5: Should value extractors be
 discoverable via the service loader?
Message-ID: <CADGJaX_upcdJPWRAGL=+PL3peN+wOzQ5W32D8of5dL3bgD_YLA@mail.gmail.com>

Hi,

I think there already was agreement essentially that value extractors
should be discoverable using the service loader mechanism.

This will allow providers of custom collection types (e.g. Google
Guava) to bundle a value extractor with their library and have it
being picked up automatically, allowing application developer to put
@Valid to these types without any further configuration.

So I've prepared a change for that:

    https://github.com/beanvalidation/beanvalidation-spec/pull/140

The open question was how value extractors should be
overridden/disabled. I've foreseen the following sources for value
extractors, in descending order of precedence:

* ValidatorContext#addValueExtractor(ValueExtractor<?>)
* Configuration#addValueExtractor(ValueExtractor<?>)
* META-INF/validation.xml
* META-INF/services/javax.validation.valueextraction.ValueExtractor

If an extractor for a specific type (e.g. java.util.List) and type
parameter (e.g. "E") is given at one level (e.g. ValidatorContext) it
will override any extractors for the same type and type parameter
given at the lower levels and the built-in extractor for that type and
type parameter, if any.

I don't think there's a way needed to explicitly disable an extractor
without providing an alternative implementation. I.e. I cannot see a
use case why one would want to disable cascaded validation let's say
for List. Hence the proposed overriding scheme.

Can you please let me know what you think of this by the end of the week?

Thanks,

--Gunnar

From emmanuel at hibernate.org  Mon Feb 20 12:04:05 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 20 Feb 2017 18:04:05 +0100
Subject: [bv-dev] Value extraction open issue #5: Should value
 extractors be discoverable via the service loader?
In-Reply-To: <CADGJaX_upcdJPWRAGL=+PL3peN+wOzQ5W32D8of5dL3bgD_YLA@mail.gmail.com>
References: <CADGJaX_upcdJPWRAGL=+PL3peN+wOzQ5W32D8of5dL3bgD_YLA@mail.gmail.com>
Message-ID: <20170220170405.GA90061@hibernate.org>

There is always the option to remove / not put @Valid and other
@Constraint annotations if one does not want an extractor to be used.
So I'm aligned with your proposal.

On Mon 17-02-20 16:54, Gunnar Morling wrote:
>Hi,
>
>I think there already was agreement essentially that value extractors
>should be discoverable using the service loader mechanism.
>
>This will allow providers of custom collection types (e.g. Google
>Guava) to bundle a value extractor with their library and have it
>being picked up automatically, allowing application developer to put
>@Valid to these types without any further configuration.
>
>So I've prepared a change for that:
>
>    https://github.com/beanvalidation/beanvalidation-spec/pull/140
>
>The open question was how value extractors should be
>overridden/disabled. I've foreseen the following sources for value
>extractors, in descending order of precedence:
>
>* ValidatorContext#addValueExtractor(ValueExtractor<?>)
>* Configuration#addValueExtractor(ValueExtractor<?>)
>* META-INF/validation.xml
>* META-INF/services/javax.validation.valueextraction.ValueExtractor
>
>If an extractor for a specific type (e.g. java.util.List) and type
>parameter (e.g. "E") is given at one level (e.g. ValidatorContext) it
>will override any extractors for the same type and type parameter
>given at the lower levels and the built-in extractor for that type and
>type parameter, if any.
>
>I don't think there's a way needed to explicitly disable an extractor
>without providing an alternative implementation. I.e. I cannot see a
>use case why one would want to disable cascaded validation let's say
>for List. Hence the proposed overriding scheme.
>
>Can you please let me know what you think of this by the end of the week?
>
>Thanks,
>
>--Gunnar
>_______________________________________________
>beanvalidation-dev mailing list
>beanvalidation-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Mon Feb 20 12:57:14 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Mon, 20 Feb 2017 14:57:14 -0300
Subject: [bv-dev] Value extraction open issue #5: Should value
 extractors be discoverable via the service loader?
In-Reply-To: <CADGJaX_upcdJPWRAGL=+PL3peN+wOzQ5W32D8of5dL3bgD_YLA@mail.gmail.com>
References: <CADGJaX_upcdJPWRAGL=+PL3peN+wOzQ5W32D8of5dL3bgD_YLA@mail.gmail.com>
Message-ID: <CAAWA2oW+mHg7fZ4GLAX4oQ+AUOTAa46x7LO2SWgsCWrV3-MgWg@mail.gmail.com>

Gunnar,

Agreed.

Regards,
Michael

On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> I think there already was agreement essentially that value extractors
> should be discoverable using the service loader mechanism.
>
> This will allow providers of custom collection types (e.g. Google
> Guava) to bundle a value extractor with their library and have it
> being picked up automatically, allowing application developer to put
> @Valid to these types without any further configuration.
>
> So I've prepared a change for that:
>
>     https://github.com/beanvalidation/beanvalidation-spec/pull/140
>
> The open question was how value extractors should be
> overridden/disabled. I've foreseen the following sources for value
> extractors, in descending order of precedence:
>
> * ValidatorContext#addValueExtractor(ValueExtractor<?>)
> * Configuration#addValueExtractor(ValueExtractor<?>)
> * META-INF/validation.xml
> * META-INF/services/javax.validation.valueextraction.ValueExtractor
>
> If an extractor for a specific type (e.g. java.util.List) and type
> parameter (e.g. "E") is given at one level (e.g. ValidatorContext) it
> will override any extractors for the same type and type parameter
> given at the lower levels and the built-in extractor for that type and
> type parameter, if any.
>
> I don't think there's a way needed to explicitly disable an extractor
> without providing an alternative implementation. I.e. I cannot see a
> use case why one would want to disable cascaded validation let's say
> for List. Hence the proposed overriding scheme.
>
> Can you please let me know what you think of this by the end of the week?
>
> 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/20170220/08258cd1/attachment.html 

From misterm at gmail.com  Mon Feb 20 14:13:35 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Mon, 20 Feb 2017 16:13:35 -0300
Subject: [bv-dev] First Alpha release of Bean Validation 2.0 RI
In-Reply-To: <CADGJaX8jYMZZkNCfqCUCavOW9UKJdcoudkLine2YFc8_xwLgyg@mail.gmail.com>
References: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>
	<CAAWA2oXS8=0Et=Y_9CczTCafiVZ1b6UTA=jLXRFWkqT1xM_udA@mail.gmail.com>
	<CALt0+o_pM4Ms3o5W1g0s9DR4rsWcx5or3PJ5MWSkvB+59j944A@mail.gmail.com>
	<CAAWA2oXYK+fmRuYUQA9VQFpysdzzarcG0LJNb1D+k+zrruAmMw@mail.gmail.com>
	<CADGJaX8jYMZZkNCfqCUCavOW9UKJdcoudkLine2YFc8_xwLgyg@mail.gmail.com>
Message-ID: <CAAWA2oXZkwEAanG+29_=g7QfYaQePNaSiko4aCeTBZzop8868Q@mail.gmail.com>

On Fri, Feb 17, 2017 at 5:11 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> > You don't compare, because they are not the same. The idea is that the
> > Period must be defined in terms of the units for which you defined its
> > boundaries.
>
> I see. I'm wondering though how practical that will be. Will the
> developer who puts the constraint always know the structure of the
> Period set to the field (data set by the application user)?
>

In the case you want it to be validated, you ought to :-)


>
> > You shouldn't support threeten-extra, but rather arbitrary
> TemporalAmounts.
> > Then threeten-extra just happen to be one of those. There must be
> something
> > like @ChronoUnitMax/@ChronoUnitMin such as:
> >
> > @ChronoUnitMax(unit=DAYS, value=1)
>
> How would that look like for a Period with several elements set, e.g.
> "3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax
> for each value of ChronoUnit (which are a lot)?
>

What do you mean by a member in @ChronoUnitMax? In my example, I suggest
using unit as a member, leading to unit and value being the only members.


> We had a discussion of Duration et al. a while ago, but it petered
> out. So we thought we'd add something to the RI to spark a new
> discussion. Seems it worked :)


Can?t disagree :-)

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

From gunnar at hibernate.org  Tue Feb 21 02:51:23 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 21 Feb 2017 08:51:23 +0100
Subject: [bv-dev] First Alpha release of Bean Validation 2.0 RI
In-Reply-To: <CAAWA2oXZkwEAanG+29_=g7QfYaQePNaSiko4aCeTBZzop8868Q@mail.gmail.com>
References: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>
	<CAAWA2oXS8=0Et=Y_9CczTCafiVZ1b6UTA=jLXRFWkqT1xM_udA@mail.gmail.com>
	<CALt0+o_pM4Ms3o5W1g0s9DR4rsWcx5or3PJ5MWSkvB+59j944A@mail.gmail.com>
	<CAAWA2oXYK+fmRuYUQA9VQFpysdzzarcG0LJNb1D+k+zrruAmMw@mail.gmail.com>
	<CADGJaX8jYMZZkNCfqCUCavOW9UKJdcoudkLine2YFc8_xwLgyg@mail.gmail.com>
	<CAAWA2oXZkwEAanG+29_=g7QfYaQePNaSiko4aCeTBZzop8868Q@mail.gmail.com>
Message-ID: <CADGJaX-HA64sEiy4JdYcOXz0R3OVnxinGAUh16RQ9Ak0SeB9bQ@mail.gmail.com>

2017-02-20 20:13 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
> On Fri, Feb 17, 2017 at 5:11 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> > You don't compare, because they are not the same. The idea is that the
>> > Period must be defined in terms of the units for which you defined its
>> > boundaries.
>>
>> I see. I'm wondering though how practical that will be. Will the
>> developer who puts the constraint always know the structure of the
>> Period set to the field (data set by the application user)?
>
>
> In the case you want it to be validated, you ought to :-)

But that's the problem, can you really?

The actual field values are set at application runtime, e.g. entered
by a user sitting in front of the application. So the application
developer would have to "lock down" whatever can be put in to match
the unit set in the constraint. It's doable but I'm having doubts that
this constraint pulls its eight eventually.

>
>>
>>
>> > You shouldn't support threeten-extra, but rather arbitrary
>> > TemporalAmounts.
>> > Then threeten-extra just happen to be one of those. There must be
>> > something
>> > like @ChronoUnitMax/@ChronoUnitMin such as:
>> >
>> > @ChronoUnitMax(unit=DAYS, value=1)
>>
>> How would that look like for a Period with several elements set, e.g.
>> "3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax
>> for each value of ChronoUnit (which are a lot)?
>
>
> What do you mean by a member in @ChronoUnitMax? In my example, I suggest
> using unit as a member, leading to unit and value being the only members.

By member I meant months(), days(), hours() etc. In the "one unit, one
value" model, how would you express "max 3 month and two weeks"? We
could exclude such case of course, it may sufficiently well be
expressed as "max 10 weeks".

>
>>
>> We had a discussion of Duration et al. a while ago, but it petered
>> out. So we thought we'd add something to the RI to spark a new
>> discussion. Seems it worked :)
>
>
> Can?t disagree :-)
>
> Regards,
> Michael
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


From christian at kaltepoth.de  Tue Feb 21 10:25:28 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Tue, 21 Feb 2017 16:25:28 +0100
Subject: [bv-dev] Value extraction open issue #5: Should value
 extractors be discoverable via the service loader?
In-Reply-To: <CAAWA2oW+mHg7fZ4GLAX4oQ+AUOTAa46x7LO2SWgsCWrV3-MgWg@mail.gmail.com>
References: <CADGJaX_upcdJPWRAGL=+PL3peN+wOzQ5W32D8of5dL3bgD_YLA@mail.gmail.com>
	<CAAWA2oW+mHg7fZ4GLAX4oQ+AUOTAa46x7LO2SWgsCWrV3-MgWg@mail.gmail.com>
Message-ID: <CAEXeC6xsDgomizp=hM2JDvtB5r4DAc0Z+dhP77oV0z-UQHd1jQ@mail.gmail.com>

Hey Gunnar,

+1 for your proposal. I also think that this overriding scheme is
sufficient and covers all the real world use cases.

Christian

2017-02-20 18:57 GMT+01:00 Michael Nascimento <misterm at gmail.com>:

> Gunnar,
>
> Agreed.
>
> Regards,
> Michael
>
> On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> I think there already was agreement essentially that value extractors
>> should be discoverable using the service loader mechanism.
>>
>> This will allow providers of custom collection types (e.g. Google
>> Guava) to bundle a value extractor with their library and have it
>> being picked up automatically, allowing application developer to put
>> @Valid to these types without any further configuration.
>>
>> So I've prepared a change for that:
>>
>>     https://github.com/beanvalidation/beanvalidation-spec/pull/140
>>
>> The open question was how value extractors should be
>> overridden/disabled. I've foreseen the following sources for value
>> extractors, in descending order of precedence:
>>
>> * ValidatorContext#addValueExtractor(ValueExtractor<?>)
>> * Configuration#addValueExtractor(ValueExtractor<?>)
>> * META-INF/validation.xml
>> * META-INF/services/javax.validation.valueextraction.ValueExtractor
>>
>> If an extractor for a specific type (e.g. java.util.List) and type
>> parameter (e.g. "E") is given at one level (e.g. ValidatorContext) it
>> will override any extractors for the same type and type parameter
>> given at the lower levels and the built-in extractor for that type and
>> type parameter, if any.
>>
>> I don't think there's a way needed to explicitly disable an extractor
>> without providing an alternative implementation. I.e. I cannot see a
>> use case why one would want to disable cascaded validation let's say
>> for List. Hence the proposed overriding scheme.
>>
>> Can you please let me know what you think of this by the end of the week?
>>
>> 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
>



-- 
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/20170221/9e54de0e/attachment.html 

From guillaume.smet at gmail.com  Wed Feb 22 11:10:23 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 22 Feb 2017 17:10:23 +0100
Subject: [bv-dev] Value extraction open issue #13 and #14: Path and nodes
Message-ID: <CALt0+o8aHfH3Tp2WdqgUGbhKtiBFyLLoptGfaTpdU_B0b9CLCg@mail.gmail.com>

Hi,

We would like to discuss with you the node structure of the
ConstraintViolation path in the case of value extraction (2 cases really:
cascaded validation and type argument constraints).

This is not an easy one! And we will also digress on the string
representation while we're at it even if it's not part of the spec.

= 1. Type parameter information

== 1.1 Should we add the type parameter to the node?

Assume the example of a map:
private Map<@Valid City (1), @Valid Statistics (2)> map;

With the current way of doing things, you end up with the following paths:
(1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
isInIterable = true, key = city)
(2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
isInIterable = true, key = city)

So you wouldn't be able to differentiate if the violations is coming from
City or Statistics.

One of the ideas we had is to integrate the TypeVariable<?> type parameter
info into the last node. In the case of (1), you would have 2 nodes:
(1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
isInIterable = true, key = city, typeParameter = K)
(2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
isInIterable = true, key = city, typeParameter = V)

WDYT?

== 1.2 If we add this information, what should it be?

At first, Gunnar thought about using java.lang.reflect.TypeVariable for
this type parameter information but we have an issue with it: it is not
serializable and the path is supposed to be.

Thus we need to either use a String with the name of the type parameter or
introduce our own serializable structure.

What's your take on this? If we go the structure route, which information
should this structure contain apart from the name?
java.lang.reflect.TypeVariable also has the generic declaration information.

Do you foresee issues if we are not using java.lang.reflect.TypeVariable?
Typically it would be harder to do additional reflection things.

= 2. Type argument constraints

So, the discussion above also applies to type argument constraints but
there are some specific questions for them.

== 2.1 New node type

Type argument constraints cover the following case, ZipCode being a
constraint:
Map<@ZipCode String, String> map;

In this case, we envision the following node structure (assuming we would
add the typeParameter discussed in 1.1):
(name = map, type = property) -> (name = '<map key>', type = TYPE_ARGUMENT,
isInIterable = true, key = myKey, typeParameter = K)

TYPE_ARGUMENT is a new type introduced in javax.validation.ElementKind.

Does it make sense?

== 2.2 Default node names

The default extractors define the following node names for the added
TYPE_ARGUMENT node:
- arrays and Iterables (List included): <iterable element>
- Map key: <map key>
- Map value: <map value>

This is similar to the nodes we created for "<return value>" or
"<cross-parameter>" constraints.

Question: should they have a node name? should it be the type parameter
name instead (so E or K or V for instance)?

Note that this might have consequences in the string representation we will
discuss later.

== 2.3 Optional and ObservableValue

In these 2 cases, we won't append a node.

Note that while in the ObservableValue case, it might feel more natural as
the constraint will probably be used like:
@NotBlank StringProperty property;
to apply a NotBlank constraint on the wrapped value so it's rather logical
to not have a node.

Just to be clear, for Optional, on the other hand, with our proposal, we
won't have a node whereas the code looks like:
Optional<@NotBlank String> optional;

= 3 String representation

Note: this is implementation specific but we thought it might be
interesting to discuss it here anyway.

The Path toString() is included in
ConstraintViolationException.getMessage().

If we consider what we proposed above and the following property:
Map<@NotNull @Valid Address, String> nicksByAddress;

We would end up with:
map<K>[address.toString()].street //error in address.street
map<K>[address.toString()].<map key> //error in type param of address
map<K>[address.toString()] //error in class level address - there is a bean
node which we don't show

If we consider the following property:
Map<String, @NotNull @Valid Address> addressesByNick;

And we decided to be consistent with the fact that we add the type
parameter information, we would end up with:
map<V>[address.toString()].street //error in address.street
map<V>[address.toString()].<map key> //error in type param of address
map<V>[address.toString()] //error in class level address - there is a bean
node which we don't show

Note that this breaks the previous behavior of HV 5.x as we used to only
support constraints on the value and we did not have the '<V>' information.

The issue becomes a bit more pregnant in the case of Lists. Let's assume we
have the following property:
List<@NotNull @Valid Address> addresses;

We would end up with:
addresses<E>[0].street //error in address.street
addresses<E>[0].<iterable element> //error in type param of address
addresses<E>[0] //error in class level address - there is a bean node which
we don't show

Question that becomes obvious here: if it were possible to only display the
type parameter if we have > 1 type parameters in the original generic
declaration, would it make sense to omit it? Basically, we have to discuss
consistency vs readability.

To completely illustrate the discussion, let's take a look at what happens
with nested type argument constraints (it is not in the spec yet but we
experimented with it in HV - we'll discuss this in a future email):
Map<String, List<@NotNull @Valid Address>> listOfAddressesByNick;

In this case, the envisioned string representation would be:
listOfAddressesByNick<V>[myKey].<map value><E>[0].street //error in
address.street
listOfAddressesByNick<V>[myKey].<map value><E>[0].<iterable element>
//error in type param of address
listOfAddressesByNick<V>[myKey].<map value><E>[0] //error in class level
address - there is a bean node which we don't show

So, as you can see, the readability can become an issue.

Thoughts? Ideas?

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

From misterm at gmail.com  Wed Feb 22 11:46:01 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 22 Feb 2017 13:46:01 -0300
Subject: [bv-dev] Value extraction open issue #13 and #14: Path and nodes
In-Reply-To: <CALt0+o8aHfH3Tp2WdqgUGbhKtiBFyLLoptGfaTpdU_B0b9CLCg@mail.gmail.com>
References: <CALt0+o8aHfH3Tp2WdqgUGbhKtiBFyLLoptGfaTpdU_B0b9CLCg@mail.gmail.com>
Message-ID: <CAAWA2oV0JoxCAvpr77tU4tRsTJ6nFUT9pc8xEHMFc=A+0SWdqA@mail.gmail.com>

On Wed, Feb 22, 2017 at 1:10 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> = 1. Type parameter information
>
> == 1.1 Should we add the type parameter to the node?
>
> Assume the example of a map:
> private Map<@Valid City (1), @Valid Statistics (2)> map;
>
> With the current way of doing things, you end up with the following paths:
> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
> isInIterable = true, key = city)
> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
> isInIterable = true, key = city)
>
> So you wouldn't be able to differentiate if the violations is coming from
> City or Statistics.
>
> One of the ideas we had is to integrate the TypeVariable<?> type parameter
> info into the last node. In the case of (1), you would have 2 nodes:
> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
> isInIterable = true, key = city, typeParameter = K)
> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
> isInIterable = true, key = city, typeParameter = V)
>
> WDYT?
>

Looks bad, type parameter names in Java are considered documentation and
not something you cannot change during class evolution. For Map, it won't
ever change, but for other domain classes, it can change.

Type parameter *order*, though, cannot change without change meaning, so
that's the best option we have left :-(


> == 1.2 If we add this information, what should it be?
>
> At first, Gunnar thought about using java.lang.reflect.TypeVariable for
> this type parameter information but we have an issue with it: it is not
> serializable and the path is supposed to be.
>
> Thus we need to either use a String with the name of the type parameter or
> introduce our own serializable structure.
>

Introduce a serializable structure. :-(

What's your take on this? If we go the structure route, which information
> should this structure contain apart from the name?
> java.lang.reflect.TypeVariable also has the generic declaration information.
>
> Do you foresee issues if we are not using java.lang.reflect.TypeVariable?
> Typically it would be harder to do additional reflection things.
>

Yeah, as the generics model evolve, we might paint ourselves in the corner.

= 2. Type argument constraints
>
> So, the discussion above also applies to type argument constraints but
> there are some specific questions for them.
>
> == 2.1 New node type
>
> Type argument constraints cover the following case, ZipCode being a
> constraint:
> Map<@ZipCode String, String> map;
>
> In this case, we envision the following node structure (assuming we would
> add the typeParameter discussed in 1.1):
> (name = map, type = property) -> (name = '<map key>', type =
> TYPE_ARGUMENT, isInIterable = true, key = myKey, typeParameter = K)
>
> TYPE_ARGUMENT is a new type introduced in javax.validation.ElementKind.
>
> Does it make sense?
>

My answer from above applies here as well.

== 2.2 Default node names
>
> The default extractors define the following node names for the added
> TYPE_ARGUMENT node:
> - arrays and Iterables (List included): <iterable element>
> - Map key: <map key>
> - Map value: <map value>
>
> This is similar to the nodes we created for "<return value>" or
> "<cross-parameter>" constraints.
>
> Question: should they have a node name? should it be the type parameter
> name instead (so E or K or V for instance)?
>
> Note that this might have consequences in the string representation we
> will discuss later.
>

If they must have a name, it will probably have to be named after the types
they apply to and type parameter order :-(


> == 2.3 Optional and ObservableValue
>
> In these 2 cases, we won't append a node.
>
> Note that while in the ObservableValue case, it might feel more natural as
> the constraint will probably be used like:
> @NotBlank StringProperty property;
> to apply a NotBlank constraint on the wrapped value so it's rather logical
> to not have a node.
>
> Just to be clear, for Optional, on the other hand, with our proposal, we
> won't have a node whereas the code looks like:
> Optional<@NotBlank String> optional;
>

Couldn't quite understand what comments I could make about it, so ok :-)

>
> = 3 String representation
>

> Note: this is implementation specific but we thought it might be
> interesting to discuss it here anyway.
>

Sorry, too many nuances and I don't have a strong opinion here.

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

From gunnar at hibernate.org  Wed Feb 22 12:13:21 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 22 Feb 2017 18:13:21 +0100
Subject: [bv-dev] Value extraction open issue #13 and #14: Path and nodes
In-Reply-To: <CAAWA2oV0JoxCAvpr77tU4tRsTJ6nFUT9pc8xEHMFc=A+0SWdqA@mail.gmail.com>
References: <CALt0+o8aHfH3Tp2WdqgUGbhKtiBFyLLoptGfaTpdU_B0b9CLCg@mail.gmail.com>
	<CAAWA2oV0JoxCAvpr77tU4tRsTJ6nFUT9pc8xEHMFc=A+0SWdqA@mail.gmail.com>
Message-ID: <CADGJaX96s7zTrNziCdU7PfMTOd4bmw7dHekrbDAM1uD24Z42tQ@mail.gmail.com>

> Looks bad, type parameter names in Java are considered documentation and not
> something you cannot change during class evolution. For Map, it won't ever
> change, but for other domain classes, it can change.

Property paths reflect on a model in a given state. If your model
evolves, e.g. because you rename a bean property, paths obtained
previously may not match any element in the model's current state
anymore.

I.e. I'm failing to see the how the situation is fundamentally
different for type parameters?

2017-02-22 17:46 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
> On Wed, Feb 22, 2017 at 1:10 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>>
>> = 1. Type parameter information
>>
>> == 1.1 Should we add the type parameter to the node?
>>
>> Assume the example of a map:
>> private Map<@Valid City (1), @Valid Statistics (2)> map;
>>
>> With the current way of doing things, you end up with the following paths:
>> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
>> isInIterable = true, key = city)
>> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
>> isInIterable = true, key = city)
>>
>> So you wouldn't be able to differentiate if the violations is coming from
>> City or Statistics.
>>
>> One of the ideas we had is to integrate the TypeVariable<?> type parameter
>> info into the last node. In the case of (1), you would have 2 nodes:
>> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
>> isInIterable = true, key = city, typeParameter = K)
>> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
>> isInIterable = true, key = city, typeParameter = V)
>>
>> WDYT?
>
>
> Looks bad, type parameter names in Java are considered documentation and not
> something you cannot change during class evolution. For Map, it won't ever
> change, but for other domain classes, it can change.
>
> Type parameter *order*, though, cannot change without change meaning, so
> that's the best option we have left :-(
>
>>
>> == 1.2 If we add this information, what should it be?
>>
>> At first, Gunnar thought about using java.lang.reflect.TypeVariable for
>> this type parameter information but we have an issue with it: it is not
>> serializable and the path is supposed to be.
>>
>> Thus we need to either use a String with the name of the type parameter or
>> introduce our own serializable structure.
>
>
> Introduce a serializable structure. :-(
>
>> What's your take on this? If we go the structure route, which information
>> should this structure contain apart from the name?
>> java.lang.reflect.TypeVariable also has the generic declaration information.
>>
>> Do you foresee issues if we are not using java.lang.reflect.TypeVariable?
>> Typically it would be harder to do additional reflection things.
>
>
> Yeah, as the generics model evolve, we might paint ourselves in the corner.
>
>> = 2. Type argument constraints
>>
>> So, the discussion above also applies to type argument constraints but
>> there are some specific questions for them.
>>
>> == 2.1 New node type
>>
>> Type argument constraints cover the following case, ZipCode being a
>> constraint:
>> Map<@ZipCode String, String> map;
>>
>> In this case, we envision the following node structure (assuming we would
>> add the typeParameter discussed in 1.1):
>> (name = map, type = property) -> (name = '<map key>', type =
>> TYPE_ARGUMENT, isInIterable = true, key = myKey, typeParameter = K)
>>
>> TYPE_ARGUMENT is a new type introduced in javax.validation.ElementKind.
>>
>> Does it make sense?
>
>
> My answer from above applies here as well.
>
>> == 2.2 Default node names
>>
>> The default extractors define the following node names for the added
>> TYPE_ARGUMENT node:
>> - arrays and Iterables (List included): <iterable element>
>> - Map key: <map key>
>> - Map value: <map value>
>>
>> This is similar to the nodes we created for "<return value>" or
>> "<cross-parameter>" constraints.
>>
>> Question: should they have a node name? should it be the type parameter
>> name instead (so E or K or V for instance)?
>>
>> Note that this might have consequences in the string representation we
>> will discuss later.
>
>
> If they must have a name, it will probably have to be named after the types
> they apply to and type parameter order :-(
>
>>
>> == 2.3 Optional and ObservableValue
>>
>> In these 2 cases, we won't append a node.
>>
>> Note that while in the ObservableValue case, it might feel more natural as
>> the constraint will probably be used like:
>> @NotBlank StringProperty property;
>> to apply a NotBlank constraint on the wrapped value so it's rather logical
>> to not have a node.
>>
>> Just to be clear, for Optional, on the other hand, with our proposal, we
>> won't have a node whereas the code looks like:
>> Optional<@NotBlank String> optional;
>
>
> Couldn't quite understand what comments I could make about it, so ok :-)
>>
>>
>> = 3 String representation
>>
>>
>> Note: this is implementation specific but we thought it might be
>> interesting to discuss it here anyway.
>
>
> Sorry, too many nuances and I don't have a strong opinion here.
>
> Regards,
> Michael
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Wed Feb 22 12:26:24 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 22 Feb 2017 14:26:24 -0300
Subject: [bv-dev] Value extraction open issue #13 and #14: Path and nodes
In-Reply-To: <CADGJaX96s7zTrNziCdU7PfMTOd4bmw7dHekrbDAM1uD24Z42tQ@mail.gmail.com>
References: <CALt0+o8aHfH3Tp2WdqgUGbhKtiBFyLLoptGfaTpdU_B0b9CLCg@mail.gmail.com>
	<CAAWA2oV0JoxCAvpr77tU4tRsTJ6nFUT9pc8xEHMFc=A+0SWdqA@mail.gmail.com>
	<CADGJaX96s7zTrNziCdU7PfMTOd4bmw7dHekrbDAM1uD24Z42tQ@mail.gmail.com>
Message-ID: <CAAWA2oVQsfx9PwQkoYVkGoBv0XuFhYNSy9rY4bmpXLo+Ny7+0A@mail.gmail.com>

Gunnar,

Maybe I'm missing the point here, but as far as I understand, names added
to the paths will be significant - for instance, it will influence how
messages will end up being formatted, because keys will now depend on this
additional information, right? If this is wrong, then disregard what I
wrote below because it's based on that assumption.

When you rename a property or a class name, client code will very likely
fail to compile. You're releasing an incompatible change - you probably
need to bump your major version in some cases and write thorough release
notes in order to do that. Now, we're saying that to BeanValidation - and
so far, in JCP standards, the only one AFAIK -, type parameter *names* are
relevant. If you rename one, your code will compile but you might end up
having a runtime exception or a poorly formatted error message because of
that, unless you explicitly test them for type parameter name change - the
only change that will not break other parts of your code. Whereas if you
really on order, a change either breaks compilation or completely changes
the semantics of existing code and has to follow the incompatible change
process.

But, as I said, what I said above is only valid if the names are
significant, i.e., used somewhere else in a meaningful way.

Regards,
Michael

On Wed, Feb 22, 2017 at 2:13 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> > Looks bad, type parameter names in Java are considered documentation and
> not
> > something you cannot change during class evolution. For Map, it won't
> ever
> > change, but for other domain classes, it can change.
>
> Property paths reflect on a model in a given state. If your model
> evolves, e.g. because you rename a bean property, paths obtained
> previously may not match any element in the model's current state
> anymore.
>
> I.e. I'm failing to see the how the situation is fundamentally
> different for type parameters?
>
> 2017-02-22 17:46 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
> > On Wed, Feb 22, 2017 at 1:10 PM, Guillaume Smet <
> guillaume.smet at gmail.com>
> > wrote:
> >>
> >> = 1. Type parameter information
> >>
> >> == 1.1 Should we add the type parameter to the node?
> >>
> >> Assume the example of a map:
> >> private Map<@Valid City (1), @Valid Statistics (2)> map;
> >>
> >> With the current way of doing things, you end up with the following
> paths:
> >> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
> >> isInIterable = true, key = city)
> >> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
> >> isInIterable = true, key = city)
> >>
> >> So you wouldn't be able to differentiate if the violations is coming
> from
> >> City or Statistics.
> >>
> >> One of the ideas we had is to integrate the TypeVariable<?> type
> parameter
> >> info into the last node. In the case of (1), you would have 2 nodes:
> >> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
> >> isInIterable = true, key = city, typeParameter = K)
> >> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
> >> isInIterable = true, key = city, typeParameter = V)
> >>
> >> WDYT?
> >
> >
> > Looks bad, type parameter names in Java are considered documentation and
> not
> > something you cannot change during class evolution. For Map, it won't
> ever
> > change, but for other domain classes, it can change.
> >
> > Type parameter *order*, though, cannot change without change meaning, so
> > that's the best option we have left :-(
> >
> >>
> >> == 1.2 If we add this information, what should it be?
> >>
> >> At first, Gunnar thought about using java.lang.reflect.TypeVariable for
> >> this type parameter information but we have an issue with it: it is not
> >> serializable and the path is supposed to be.
> >>
> >> Thus we need to either use a String with the name of the type parameter
> or
> >> introduce our own serializable structure.
> >
> >
> > Introduce a serializable structure. :-(
> >
> >> What's your take on this? If we go the structure route, which
> information
> >> should this structure contain apart from the name?
> >> java.lang.reflect.TypeVariable also has the generic declaration
> information.
> >>
> >> Do you foresee issues if we are not using java.lang.reflect.
> TypeVariable?
> >> Typically it would be harder to do additional reflection things.
> >
> >
> > Yeah, as the generics model evolve, we might paint ourselves in the
> corner.
> >
> >> = 2. Type argument constraints
> >>
> >> So, the discussion above also applies to type argument constraints but
> >> there are some specific questions for them.
> >>
> >> == 2.1 New node type
> >>
> >> Type argument constraints cover the following case, ZipCode being a
> >> constraint:
> >> Map<@ZipCode String, String> map;
> >>
> >> In this case, we envision the following node structure (assuming we
> would
> >> add the typeParameter discussed in 1.1):
> >> (name = map, type = property) -> (name = '<map key>', type =
> >> TYPE_ARGUMENT, isInIterable = true, key = myKey, typeParameter = K)
> >>
> >> TYPE_ARGUMENT is a new type introduced in javax.validation.ElementKind.
> >>
> >> Does it make sense?
> >
> >
> > My answer from above applies here as well.
> >
> >> == 2.2 Default node names
> >>
> >> The default extractors define the following node names for the added
> >> TYPE_ARGUMENT node:
> >> - arrays and Iterables (List included): <iterable element>
> >> - Map key: <map key>
> >> - Map value: <map value>
> >>
> >> This is similar to the nodes we created for "<return value>" or
> >> "<cross-parameter>" constraints.
> >>
> >> Question: should they have a node name? should it be the type parameter
> >> name instead (so E or K or V for instance)?
> >>
> >> Note that this might have consequences in the string representation we
> >> will discuss later.
> >
> >
> > If they must have a name, it will probably have to be named after the
> types
> > they apply to and type parameter order :-(
> >
> >>
> >> == 2.3 Optional and ObservableValue
> >>
> >> In these 2 cases, we won't append a node.
> >>
> >> Note that while in the ObservableValue case, it might feel more natural
> as
> >> the constraint will probably be used like:
> >> @NotBlank StringProperty property;
> >> to apply a NotBlank constraint on the wrapped value so it's rather
> logical
> >> to not have a node.
> >>
> >> Just to be clear, for Optional, on the other hand, with our proposal, we
> >> won't have a node whereas the code looks like:
> >> Optional<@NotBlank String> optional;
> >
> >
> > Couldn't quite understand what comments I could make about it, so ok :-)
> >>
> >>
> >> = 3 String representation
> >>
> >>
> >> Note: this is implementation specific but we thought it might be
> >> interesting to discuss it here anyway.
> >
> >
> > Sorry, too many nuances and I don't have a strong opinion here.
> >
> > Regards,
> > Michael
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170222/cc686c4a/attachment.html 

From moltenma at gmail.com  Wed Feb 22 16:32:52 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Wed, 22 Feb 2017 22:32:52 +0100
Subject: [bv-dev] Value extraction open issue #5: Should value
 extractors be discoverable via the service loader?
In-Reply-To: <CAEXeC6xsDgomizp=hM2JDvtB5r4DAc0Z+dhP77oV0z-UQHd1jQ@mail.gmail.com>
References: <CADGJaX_upcdJPWRAGL=+PL3peN+wOzQ5W32D8of5dL3bgD_YLA@mail.gmail.com>
	<CAAWA2oW+mHg7fZ4GLAX4oQ+AUOTAa46x7LO2SWgsCWrV3-MgWg@mail.gmail.com>
	<CAEXeC6xsDgomizp=hM2JDvtB5r4DAc0Z+dhP77oV0z-UQHd1jQ@mail.gmail.com>
Message-ID: <CANUPYM257nMHaVY3oJz74=LKtdDdvPDeBro=mOhdKuL49RXCvQ@mail.gmail.com>

Agreed. Thanks Gunnar.

On Tue, Feb 21, 2017 at 4:25 PM, Christian Kaltepoth <christian at kaltepoth.de
> wrote:

> Hey Gunnar,
>
> +1 for your proposal. I also think that this overriding scheme is
> sufficient and covers all the real world use cases.
>
> Christian
>
> 2017-02-20 18:57 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
>
>> Gunnar,
>>
>> Agreed.
>>
>> Regards,
>> Michael
>>
>> On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> Hi,
>>>
>>> I think there already was agreement essentially that value extractors
>>> should be discoverable using the service loader mechanism.
>>>
>>> This will allow providers of custom collection types (e.g. Google
>>> Guava) to bundle a value extractor with their library and have it
>>> being picked up automatically, allowing application developer to put
>>> @Valid to these types without any further configuration.
>>>
>>> So I've prepared a change for that:
>>>
>>>     https://github.com/beanvalidation/beanvalidation-spec/pull/140
>>>
>>> The open question was how value extractors should be
>>> overridden/disabled. I've foreseen the following sources for value
>>> extractors, in descending order of precedence:
>>>
>>> * ValidatorContext#addValueExtractor(ValueExtractor<?>)
>>> * Configuration#addValueExtractor(ValueExtractor<?>)
>>> * META-INF/validation.xml
>>> * META-INF/services/javax.validation.valueextraction.ValueExtractor
>>>
>>> If an extractor for a specific type (e.g. java.util.List) and type
>>> parameter (e.g. "E") is given at one level (e.g. ValidatorContext) it
>>> will override any extractors for the same type and type parameter
>>> given at the lower levels and the built-in extractor for that type and
>>> type parameter, if any.
>>>
>>> I don't think there's a way needed to explicitly disable an extractor
>>> without providing an alternative implementation. I.e. I cannot see a
>>> use case why one would want to disable cascaded validation let's say
>>> for List. Hence the proposed overriding scheme.
>>>
>>> Can you please let me know what you think of this by the end of the week?
>>>
>>> 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
>>
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170222/0cb320eb/attachment-0001.html 

From moltenma at gmail.com  Wed Feb 22 17:34:24 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Wed, 22 Feb 2017 23:34:24 +0100
Subject: [bv-dev] First Alpha release of Bean Validation 2.0 RI
In-Reply-To: <CADGJaX-HA64sEiy4JdYcOXz0R3OVnxinGAUh16RQ9Ak0SeB9bQ@mail.gmail.com>
References: <CADGJaX9AuK9wFBaGd=0PZsParyF=wmtYV-Ghus5pjbizvhVQ_Q@mail.gmail.com>
	<CAAWA2oXS8=0Et=Y_9CczTCafiVZ1b6UTA=jLXRFWkqT1xM_udA@mail.gmail.com>
	<CALt0+o_pM4Ms3o5W1g0s9DR4rsWcx5or3PJ5MWSkvB+59j944A@mail.gmail.com>
	<CAAWA2oXYK+fmRuYUQA9VQFpysdzzarcG0LJNb1D+k+zrruAmMw@mail.gmail.com>
	<CADGJaX8jYMZZkNCfqCUCavOW9UKJdcoudkLine2YFc8_xwLgyg@mail.gmail.com>
	<CAAWA2oXZkwEAanG+29_=g7QfYaQePNaSiko4aCeTBZzop8868Q@mail.gmail.com>
	<CADGJaX-HA64sEiy4JdYcOXz0R3OVnxinGAUh16RQ9Ak0SeB9bQ@mail.gmail.com>
Message-ID: <CANUPYM3Fr54VriZapu24dQWbD34=dYHN2Fd3ggkwqOtCSpARqw@mail.gmail.com>

Michael I see the business case for the Period validation, but the
complexity (impossibility) of a reliable comparison between Periods it
seems widespread and accepted between the developers. Personally I don't
see the benefits to have it in the spec if it risks to generate confusion
or errors.

If you have some inputs, these are welcome. Could you enrich your previous
example (years, month, days)?

Thanks

On Tue, Feb 21, 2017 at 8:51 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2017-02-20 20:13 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
> > On Fri, Feb 17, 2017 at 5:11 AM, Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> >>
> >> > You don't compare, because they are not the same. The idea is that the
> >> > Period must be defined in terms of the units for which you defined its
> >> > boundaries.
> >>
> >> I see. I'm wondering though how practical that will be. Will the
> >> developer who puts the constraint always know the structure of the
> >> Period set to the field (data set by the application user)?
> >
> >
> > In the case you want it to be validated, you ought to :-)
>
> But that's the problem, can you really?
>
> The actual field values are set at application runtime, e.g. entered
> by a user sitting in front of the application. So the application
> developer would have to "lock down" whatever can be put in to match
> the unit set in the constraint. It's doable but I'm having doubts that
> this constraint pulls its eight eventually.
>
> >
> >>
> >>
> >> > You shouldn't support threeten-extra, but rather arbitrary
> >> > TemporalAmounts.
> >> > Then threeten-extra just happen to be one of those. There must be
> >> > something
> >> > like @ChronoUnitMax/@ChronoUnitMin such as:
> >> >
> >> > @ChronoUnitMax(unit=DAYS, value=1)
> >>
> >> How would that look like for a Period with several elements set, e.g.
> >> "3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax
> >> for each value of ChronoUnit (which are a lot)?
> >
> >
> > What do you mean by a member in @ChronoUnitMax? In my example, I suggest
> > using unit as a member, leading to unit and value being the only members.
>
> By member I meant months(), days(), hours() etc. In the "one unit, one
> value" model, how would you express "max 3 month and two weeks"? We
> could exclude such case of course, it may sufficiently well be
> expressed as "max 10 weeks".
>
> >
> >>
> >> We had a discussion of Duration et al. a while ago, but it petered
> >> out. So we thought we'd add something to the RI to spark a new
> >> discussion. Seems it worked :)
> >
> >
> > Can?t disagree :-)
> >
> > Regards,
> > Michael
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170222/8b93765d/attachment.html 

From gunnar at hibernate.org  Thu Feb 23 05:21:50 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 23 Feb 2017 11:21:50 +0100
Subject: [bv-dev] Value extraction open issue #13 and #14: Path and nodes
In-Reply-To: <CAAWA2oVQsfx9PwQkoYVkGoBv0XuFhYNSy9rY4bmpXLo+Ny7+0A@mail.gmail.com>
References: <CALt0+o8aHfH3Tp2WdqgUGbhKtiBFyLLoptGfaTpdU_B0b9CLCg@mail.gmail.com>
	<CAAWA2oV0JoxCAvpr77tU4tRsTJ6nFUT9pc8xEHMFc=A+0SWdqA@mail.gmail.com>
	<CADGJaX96s7zTrNziCdU7PfMTOd4bmw7dHekrbDAM1uD24Z42tQ@mail.gmail.com>
	<CAAWA2oVQsfx9PwQkoYVkGoBv0XuFhYNSy9rY4bmpXLo+Ny7+0A@mail.gmail.com>
Message-ID: <CADGJaX-Wjy=BTDGPasokv=fO0oWpHdtVVp841qO2pf-rKV_XFA@mail.gmail.com>

Hi Michael,

The names of nodes in property paths have no influence on method
interpolation. They are additional information contained (besides the
message) in constraint violations.

But your hint on relying on the index is a good one: we may represent
constrained type uses with the name *and* index, just as we do it for
ParameterNode in BV 1.1.

--Gunnar


2017-02-22 18:26 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
> Gunnar,
>
> Maybe I'm missing the point here, but as far as I understand, names added to
> the paths will be significant - for instance, it will influence how messages
> will end up being formatted, because keys will now depend on this additional
> information, right? If this is wrong, then disregard what I wrote below
> because it's based on that assumption.
>
> When you rename a property or a class name, client code will very likely
> fail to compile. You're releasing an incompatible change - you probably need
> to bump your major version in some cases and write thorough release notes in
> order to do that. Now, we're saying that to BeanValidation - and so far, in
> JCP standards, the only one AFAIK -, type parameter *names* are relevant. If
> you rename one, your code will compile but you might end up having a runtime
> exception or a poorly formatted error message because of that, unless you
> explicitly test them for type parameter name change - the only change that
> will not break other parts of your code. Whereas if you really on order, a
> change either breaks compilation or completely changes the semantics of
> existing code and has to follow the incompatible change process.
>
> But, as I said, what I said above is only valid if the names are
> significant, i.e., used somewhere else in a meaningful way.
>
> Regards,
> Michael
>
> On Wed, Feb 22, 2017 at 2:13 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> > Looks bad, type parameter names in Java are considered documentation and
>> > not
>> > something you cannot change during class evolution. For Map, it won't
>> > ever
>> > change, but for other domain classes, it can change.
>>
>> Property paths reflect on a model in a given state. If your model
>> evolves, e.g. because you rename a bean property, paths obtained
>> previously may not match any element in the model's current state
>> anymore.
>>
>> I.e. I'm failing to see the how the situation is fundamentally
>> different for type parameters?
>>
>> 2017-02-22 17:46 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
>> > On Wed, Feb 22, 2017 at 1:10 PM, Guillaume Smet
>> > <guillaume.smet at gmail.com>
>> > wrote:
>> >>
>> >> = 1. Type parameter information
>> >>
>> >> == 1.1 Should we add the type parameter to the node?
>> >>
>> >> Assume the example of a map:
>> >> private Map<@Valid City (1), @Valid Statistics (2)> map;
>> >>
>> >> With the current way of doing things, you end up with the following
>> >> paths:
>> >> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
>> >> isInIterable = true, key = city)
>> >> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
>> >> isInIterable = true, key = city)
>> >>
>> >> So you wouldn't be able to differentiate if the violations is coming
>> >> from
>> >> City or Statistics.
>> >>
>> >> One of the ideas we had is to integrate the TypeVariable<?> type
>> >> parameter
>> >> info into the last node. In the case of (1), you would have 2 nodes:
>> >> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
>> >> isInIterable = true, key = city, typeParameter = K)
>> >> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
>> >> isInIterable = true, key = city, typeParameter = V)
>> >>
>> >> WDYT?
>> >
>> >
>> > Looks bad, type parameter names in Java are considered documentation and
>> > not
>> > something you cannot change during class evolution. For Map, it won't
>> > ever
>> > change, but for other domain classes, it can change.
>> >
>> > Type parameter *order*, though, cannot change without change meaning, so
>> > that's the best option we have left :-(
>> >
>> >>
>> >> == 1.2 If we add this information, what should it be?
>> >>
>> >> At first, Gunnar thought about using java.lang.reflect.TypeVariable for
>> >> this type parameter information but we have an issue with it: it is not
>> >> serializable and the path is supposed to be.
>> >>
>> >> Thus we need to either use a String with the name of the type parameter
>> >> or
>> >> introduce our own serializable structure.
>> >
>> >
>> > Introduce a serializable structure. :-(
>> >
>> >> What's your take on this? If we go the structure route, which
>> >> information
>> >> should this structure contain apart from the name?
>> >> java.lang.reflect.TypeVariable also has the generic declaration
>> >> information.
>> >>
>> >> Do you foresee issues if we are not using
>> >> java.lang.reflect.TypeVariable?
>> >> Typically it would be harder to do additional reflection things.
>> >
>> >
>> > Yeah, as the generics model evolve, we might paint ourselves in the
>> > corner.
>> >
>> >> = 2. Type argument constraints
>> >>
>> >> So, the discussion above also applies to type argument constraints but
>> >> there are some specific questions for them.
>> >>
>> >> == 2.1 New node type
>> >>
>> >> Type argument constraints cover the following case, ZipCode being a
>> >> constraint:
>> >> Map<@ZipCode String, String> map;
>> >>
>> >> In this case, we envision the following node structure (assuming we
>> >> would
>> >> add the typeParameter discussed in 1.1):
>> >> (name = map, type = property) -> (name = '<map key>', type =
>> >> TYPE_ARGUMENT, isInIterable = true, key = myKey, typeParameter = K)
>> >>
>> >> TYPE_ARGUMENT is a new type introduced in javax.validation.ElementKind.
>> >>
>> >> Does it make sense?
>> >
>> >
>> > My answer from above applies here as well.
>> >
>> >> == 2.2 Default node names
>> >>
>> >> The default extractors define the following node names for the added
>> >> TYPE_ARGUMENT node:
>> >> - arrays and Iterables (List included): <iterable element>
>> >> - Map key: <map key>
>> >> - Map value: <map value>
>> >>
>> >> This is similar to the nodes we created for "<return value>" or
>> >> "<cross-parameter>" constraints.
>> >>
>> >> Question: should they have a node name? should it be the type parameter
>> >> name instead (so E or K or V for instance)?
>> >>
>> >> Note that this might have consequences in the string representation we
>> >> will discuss later.
>> >
>> >
>> > If they must have a name, it will probably have to be named after the
>> > types
>> > they apply to and type parameter order :-(
>> >
>> >>
>> >> == 2.3 Optional and ObservableValue
>> >>
>> >> In these 2 cases, we won't append a node.
>> >>
>> >> Note that while in the ObservableValue case, it might feel more natural
>> >> as
>> >> the constraint will probably be used like:
>> >> @NotBlank StringProperty property;
>> >> to apply a NotBlank constraint on the wrapped value so it's rather
>> >> logical
>> >> to not have a node.
>> >>
>> >> Just to be clear, for Optional, on the other hand, with our proposal,
>> >> we
>> >> won't have a node whereas the code looks like:
>> >> Optional<@NotBlank String> optional;
>> >
>> >
>> > Couldn't quite understand what comments I could make about it, so ok :-)
>> >>
>> >>
>> >> = 3 String representation
>> >>
>> >>
>> >> Note: this is implementation specific but we thought it might be
>> >> interesting to discuss it here anyway.
>> >
>> >
>> > Sorry, too many nuances and I don't have a strong opinion here.
>> >
>> > Regards,
>> > Michael
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Thu Feb 23 05:24:22 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 23 Feb 2017 11:24:22 +0100
Subject: [bv-dev] Value extraction open issue #5: Should value
 extractors be discoverable via the service loader?
In-Reply-To: <CANUPYM257nMHaVY3oJz74=LKtdDdvPDeBro=mOhdKuL49RXCvQ@mail.gmail.com>
References: <CADGJaX_upcdJPWRAGL=+PL3peN+wOzQ5W32D8of5dL3bgD_YLA@mail.gmail.com>
	<CAAWA2oW+mHg7fZ4GLAX4oQ+AUOTAa46x7LO2SWgsCWrV3-MgWg@mail.gmail.com>
	<CAEXeC6xsDgomizp=hM2JDvtB5r4DAc0Z+dhP77oV0z-UQHd1jQ@mail.gmail.com>
	<CANUPYM257nMHaVY3oJz74=LKtdDdvPDeBro=mOhdKuL49RXCvQ@mail.gmail.com>
Message-ID: <CADGJaX9a3iN8W_3dbrfvUO2ndeEyAQGU_3EEqDR-_EsLSjxHow@mail.gmail.com>

As there's agreement on this approach in general, I've moved forward
and filed a PR with the API change:

    https://github.com/beanvalidation/beanvalidation-api/pull/89

Feedback welcome!

--Gunnar


2017-02-22 22:32 GMT+01:00 Marco Molteni <moltenma at gmail.com>:
> Agreed. Thanks Gunnar.
>
> On Tue, Feb 21, 2017 at 4:25 PM, Christian Kaltepoth
> <christian at kaltepoth.de> wrote:
>>
>> Hey Gunnar,
>>
>> +1 for your proposal. I also think that this overriding scheme is
>> sufficient and covers all the real world use cases.
>>
>> Christian
>>
>> 2017-02-20 18:57 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
>>>
>>> Gunnar,
>>>
>>> Agreed.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think there already was agreement essentially that value extractors
>>>> should be discoverable using the service loader mechanism.
>>>>
>>>> This will allow providers of custom collection types (e.g. Google
>>>> Guava) to bundle a value extractor with their library and have it
>>>> being picked up automatically, allowing application developer to put
>>>> @Valid to these types without any further configuration.
>>>>
>>>> So I've prepared a change for that:
>>>>
>>>>     https://github.com/beanvalidation/beanvalidation-spec/pull/140
>>>>
>>>> The open question was how value extractors should be
>>>> overridden/disabled. I've foreseen the following sources for value
>>>> extractors, in descending order of precedence:
>>>>
>>>> * ValidatorContext#addValueExtractor(ValueExtractor<?>)
>>>> * Configuration#addValueExtractor(ValueExtractor<?>)
>>>> * META-INF/validation.xml
>>>> * META-INF/services/javax.validation.valueextraction.ValueExtractor
>>>>
>>>> If an extractor for a specific type (e.g. java.util.List) and type
>>>> parameter (e.g. "E") is given at one level (e.g. ValidatorContext) it
>>>> will override any extractors for the same type and type parameter
>>>> given at the lower levels and the built-in extractor for that type and
>>>> type parameter, if any.
>>>>
>>>> I don't think there's a way needed to explicitly disable an extractor
>>>> without providing an alternative implementation. I.e. I cannot see a
>>>> use case why one would want to disable cascaded validation let's say
>>>> for List. Hence the proposed overriding scheme.
>>>>
>>>> Can you please let me know what you think of this by the end of the
>>>> week?
>>>>
>>>> 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
>>
>>
>>
>>
>> --
>> 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

From hendrik.ebbers at me.com  Thu Feb 23 07:34:35 2017
From: hendrik.ebbers at me.com (Hendrik Ebbers)
Date: Thu, 23 Feb 2017 13:34:35 +0100
Subject: [bv-dev] Sticker
Message-ID: <926E9F15-A77E-4650-AEFC-C05F64204F84@me.com>

Hi,

I attached a preview of the sticker. I will order in now :)

Cheers,

Hendrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170223/053b72ba/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bv-logo.png
Type: image/png
Size: 155332 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170223/053b72ba/attachment-0001.png 

From gunnar at hibernate.org  Thu Feb 23 08:03:19 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 23 Feb 2017 14:03:19 +0100
Subject: [bv-dev] Sticker
In-Reply-To: <926E9F15-A77E-4650-AEFC-C05F64204F84@me.com>
References: <926E9F15-A77E-4650-AEFC-C05F64204F84@me.com>
Message-ID: <CADGJaX-yjTw43Ew6b9SA0mSWica0HsQd8Qxou_s+ch21GXdhYQ@mail.gmail.com>

Awesome, that looks great, Hendrik! Looking forward to getting one :)

2017-02-23 13:34 GMT+01:00 Hendrik Ebbers <hendrik.ebbers at me.com>:

> Hi,
>
> I attached a preview of the sticker. I will order in now :)
>
> Cheers,
>
> Hendrik
>
>
> _______________________________________________
> 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/20170223/a5df4fd3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bv-logo.png
Type: image/png
Size: 155332 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170223/a5df4fd3/attachment-0001.png 

From hendrik.ebbers at me.com  Thu Feb 23 08:08:26 2017
From: hendrik.ebbers at me.com (Hendrik Ebbers)
Date: Thu, 23 Feb 2017 14:08:26 +0100
Subject: [bv-dev] Sticker
In-Reply-To: <CADGJaX-yjTw43Ew6b9SA0mSWica0HsQd8Qxou_s+ch21GXdhYQ@mail.gmail.com>
References: <926E9F15-A77E-4650-AEFC-C05F64204F84@me.com>
	<CADGJaX-yjTw43Ew6b9SA0mSWica0HsQd8Qxou_s+ch21GXdhYQ@mail.gmail.com>
Message-ID: <B1856097-C14D-4844-AD0D-F3D08326C5E5@me.com>

JavaLand ;)

> Am 23.02.2017 um 14:03 schrieb Gunnar Morling <gunnar at hibernate.org>:
> 
> Awesome, that looks great, Hendrik! Looking forward to getting one :)
> 
> 2017-02-23 13:34 GMT+01:00 Hendrik Ebbers <hendrik.ebbers at me.com <mailto:hendrik.ebbers at me.com>>:
> Hi,
> 
> I attached a preview of the sticker. I will order in now :)
> 
> Cheers,
> 
> Hendrik
> 
> <bv-logo.png>
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org <mailto:beanvalidation-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev <https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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

From moltenma at gmail.com  Thu Feb 23 16:47:47 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Thu, 23 Feb 2017 22:47:47 +0100
Subject: [bv-dev] Sticker
In-Reply-To: <B1856097-C14D-4844-AD0D-F3D08326C5E5@me.com>
References: <926E9F15-A77E-4650-AEFC-C05F64204F84@me.com>
	<CADGJaX-yjTw43Ew6b9SA0mSWica0HsQd8Qxou_s+ch21GXdhYQ@mail.gmail.com>
	<B1856097-C14D-4844-AD0D-F3D08326C5E5@me.com>
Message-ID: <CANUPYM1hc=34BqpMSSdNWN=9C8+C5usyCGaE+7SbcVJfvH2rCA@mail.gmail.com>

Very nice indeed :)

On Thu, Feb 23, 2017 at 2:08 PM, Hendrik Ebbers <hendrik.ebbers at me.com>
wrote:

> JavaLand ;)
>
> Am 23.02.2017 um 14:03 schrieb Gunnar Morling <gunnar at hibernate.org>:
>
> Awesome, that looks great, Hendrik! Looking forward to getting one :)
>
> 2017-02-23 13:34 GMT+01:00 Hendrik Ebbers <hendrik.ebbers at me.com>:
>
>> Hi,
>>
>> I attached a preview of the sticker. I will order in now :)
>>
>> Cheers,
>>
>> Hendrik
>>
>> <bv-logo.png>
>>
>> _______________________________________________
>> 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/20170223/b7aa8d29/attachment.html