From gunnar at hibernate.org  Fri Dec  2 10:20:29 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 2 Dec 2016 16:20:29 +0100
Subject: [bv-dev] Type use constraints for field *and* property
Message-ID: <CADGJaX8QY=H-wSsVVoMzm8fo6jJk7RCtJhLxcvRoczON+3d+=Q@mail.gmail.com>

Hi,

As you may have seen, Emmanuel started a survey on how people would like to
use type-level constraints in Bean Validation:
http://beanvalidation.org/news/2016/11/23/survey-constraints-and-parameterized-type/

While we are waiting for some more replies to that one, I started with a
PoC implementation of the value extractor idea in the reference
implementation in order to get a better feeling for it, it's limitations,
open questions etc.:
https://github.com/hibernate/hibernate-validator/pull/592

One thing we started to wonder is whether it should be allowed to put
type-level constraints to a field *and* the corresponding property getter
at the same time:

    private List<@NotBlank String> strings;

    public List<@Pattern(regexp="...") String> getStrings() { return
strings; }

My first inclination was to say that it should be supported (as you can put
regular constraints to a field and its getter). A challenge is how to
obtain the values for constraint validation. In the spirit of BV 1 we'd
have to iterate the values directly from the field for evaluating the
@NotBlank constraint and a second time through the getter for @Pattern
validation. That's a potential performance issue of course.

What do others think?

Thanks,

--Gunnar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161202/34efc413/attachment-0001.html 

From mbenson at apache.org  Fri Dec  2 11:22:48 2016
From: mbenson at apache.org (Matt Benson)
Date: Fri, 2 Dec 2016 10:22:48 -0600
Subject: [bv-dev] Type use constraints for field *and* property
In-Reply-To: <CADGJaX8QY=H-wSsVVoMzm8fo6jJk7RCtJhLxcvRoczON+3d+=Q@mail.gmail.com>
References: <CADGJaX8QY=H-wSsVVoMzm8fo6jJk7RCtJhLxcvRoczON+3d+=Q@mail.gmail.com>
Message-ID: <CAE9L6G2468Tc=ByDxV1FA7_umWVED_15NZCsu=fkwXH6KHgvvw@mail.gmail.com>

As far as this goes, I agree that it makes sense to be flexible and
consistent with earlier specification versions; i.e. to permit annotation
of type parameters both on fields and their associated accessor methods.

With regard to the mechanism used for reaching the validated contained
values, my feeling is that some combination of the proposals at [1] is
correct (i.e. the explicitness of the original proposal plus the aspect of
your proposal to combine the extracted value with the associated
path/node). It would probably also be helpful to provide an
annotation-based shorthand for class developers to mark the extracted
elements of custom container types without having to write an extractor
implementation (which ties into my otherwise clueless response on an
earlier thread ;) ).

Matt

1.http://beanvalidation.org/proposals/BVAL-508/

On Dec 2, 2016 9:20 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> Hi,
>
> As you may have seen, Emmanuel started a survey on how people would like
> to use type-level constraints in Bean Validation: http://
> beanvalidation.org/news/2016/11/23/survey-constraints-and-
> parameterized-type/
>
> While we are waiting for some more replies to that one, I started with a
> PoC implementation of the value extractor idea in the reference
> implementation in order to get a better feeling for it, it's limitations,
> open questions etc.: https://github.com/hibernate/
> hibernate-validator/pull/592
>
> One thing we started to wonder is whether it should be allowed to put
> type-level constraints to a field *and* the corresponding property getter
> at the same time:
>
>     private List<@NotBlank String> strings;
>
>     public List<@Pattern(regexp="...") String> getStrings() { return
> strings; }
>
> My first inclination was to say that it should be supported (as you can
> put regular constraints to a field and its getter). A challenge is how to
> obtain the values for constraint validation. In the spirit of BV 1 we'd
> have to iterate the values directly from the field for evaluating the
> @NotBlank constraint and a second time through the getter for @Pattern
> validation. That's a potential performance issue of course.
>
> What do others think?
>
> Thanks,
>
> --Gunnar
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161202/6d250e4e/attachment.html 

From christian at kaltepoth.de  Sun Dec  4 03:06:49 2016
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Sun, 4 Dec 2016 09:06:49 +0100
Subject: [bv-dev] Type use constraints for field *and* property
In-Reply-To: <CAE9L6G2468Tc=ByDxV1FA7_umWVED_15NZCsu=fkwXH6KHgvvw@mail.gmail.com>
References: <CADGJaX8QY=H-wSsVVoMzm8fo6jJk7RCtJhLxcvRoczON+3d+=Q@mail.gmail.com>
	<CAE9L6G2468Tc=ByDxV1FA7_umWVED_15NZCsu=fkwXH6KHgvvw@mail.gmail.com>
Message-ID: <CAEXeC6zKqpWveLPa7rZWFSgJaZidjzM8bi1J5XCrv3LZays6xg@mail.gmail.com>

I agree with Matt here.

I would prefer to be consistent over dropping consistency for improved
performance in some cases.

So +1 for allowing constraints on both fields and getters.

Christian

2016-12-02 17:22 GMT+01:00 Matt Benson <mbenson at apache.org>:

> As far as this goes, I agree that it makes sense to be flexible and
> consistent with earlier specification versions; i.e. to permit annotation
> of type parameters both on fields and their associated accessor methods.
>
> With regard to the mechanism used for reaching the validated contained
> values, my feeling is that some combination of the proposals at [1] is
> correct (i.e. the explicitness of the original proposal plus the aspect of
> your proposal to combine the extracted value with the associated
> path/node). It would probably also be helpful to provide an
> annotation-based shorthand for class developers to mark the extracted
> elements of custom container types without having to write an extractor
> implementation (which ties into my otherwise clueless response on an
> earlier thread ;) ).
>
> Matt
>
> 1.http://beanvalidation.org/proposals/BVAL-508/
>
> On Dec 2, 2016 9:20 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>
>> Hi,
>>
>> As you may have seen, Emmanuel started a survey on how people would like
>> to use type-level constraints in Bean Validation: http://beanvalidat
>> ion.org/news/2016/11/23/survey-constraints-and-parameterized-type/
>>
>> While we are waiting for some more replies to that one, I started with a
>> PoC implementation of the value extractor idea in the reference
>> implementation in order to get a better feeling for it, it's limitations,
>> open questions etc.: https://github.com/hibernate/h
>> ibernate-validator/pull/592
>>
>> One thing we started to wonder is whether it should be allowed to put
>> type-level constraints to a field *and* the corresponding property getter
>> at the same time:
>>
>>     private List<@NotBlank String> strings;
>>
>>     public List<@Pattern(regexp="...") String> getStrings() { return
>> strings; }
>>
>> My first inclination was to say that it should be supported (as you can
>> put regular constraints to a field and its getter). A challenge is how to
>> obtain the values for constraint validation. In the spirit of BV 1 we'd
>> have to iterate the values directly from the field for evaluating the
>> @NotBlank constraint and a second time through the getter for @Pattern
>> validation. That's a potential performance issue of course.
>>
>> What do others think?
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>



-- 
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/20161204/b7fe9a05/attachment.html 

From hardy at hibernate.org  Mon Dec  5 15:25:22 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 5 Dec 2016 21:25:22 +0100
Subject: [bv-dev] Type use constraints for field *and* property
In-Reply-To: <CAEXeC6zKqpWveLPa7rZWFSgJaZidjzM8bi1J5XCrv3LZays6xg@mail.gmail.com>
References: <CADGJaX8QY=H-wSsVVoMzm8fo6jJk7RCtJhLxcvRoczON+3d+=Q@mail.gmail.com>
	<CAE9L6G2468Tc=ByDxV1FA7_umWVED_15NZCsu=fkwXH6KHgvvw@mail.gmail.com>
	<CAEXeC6zKqpWveLPa7rZWFSgJaZidjzM8bi1J5XCrv3LZays6xg@mail.gmail.com>
Message-ID: <20161205202522.GA27493@nineveh.lan>

Hi,

On Sun, 04-Dec-2016 09:06, Christian Kaltepoth wrote:

> I would prefer to be consistent over dropping consistency for improved
> performance in some cases.

+1 It always has been a principle of Hibernate Validator to be consistent in
the first place.
 
> So +1 for allowing constraints on both fields and getters.

+1

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161205/b2d2f821/attachment.bin 

From gunnar at hibernate.org  Thu Dec 22 11:15:08 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 22 Dec 2016 17:15:08 +0100
Subject: [bv-dev] Updated proposal for container value extraction
Message-ID: <CADGJaX80+RdeE6HfDvq5sEf6gfWUjTQboPKBA6tF5b=BXCr7MA@mail.gmail.com>

Hi,

It has been silent on the surface, but that doesn't mean we haven't been busy :)

I've spent some time working on a proof of concept implementation of
the value extraction proposal (BVAL-508) which has been added to the
RI earlier this week [1]. This effort brought a fair bit of insights
and clarity which is reflected in an updated proposal that you can
find at [2].

So if you can spend some time and review it, that'd be much
appreciated. It's a bit more formalized than the original proposal and
also takes an opinion on some of the original questions. I tried to
cut down a bit on the many loose ends to advance the matter a bit, but
if you are doubtful about any of the directions taken, please speak
up.

Also the ValueExtractor contract has evolved a bit. It now allows for
a nicely uniform, yet efficient implementation of the single value and
multi value case. Refer to the pull request for the details. There are
some open questions at the end of the document. Feedback on these (and
of course any other parts of the document) are highly welcome. I've
checked on the previous threads and discussions of the matter (e.g.
Hendrik's extensive feedback) and hope the proposal covers all the
essential items. Please let me know if anything is missing.

The idea is that we add this version of the proposal as an appendix to
the spec, adjust the RI to conform with it (it already does more or
less) so we can aim for a first alpha release of spec and RI very
early next year. That will allow people to get their hands on this
feature and play around with it a bit, hopefully resulting in some
more feedback from the outside, too.

My main remaining questions are:

* Is allowing to put constraints to an element but automatically
applying them to the wrapped value the right thing to do? I can see
the concerns about lacking comprehensibility (it's working based on
the presence of an automatically unwrapping value extractor), but then
it's needed to support "@Email StringProperty email"
* Should we support nested collections (e.g. List<Map<String, @NotNull
String>> addressesByType). It hasn't been supported before, but I can
see how it's more appealing with type parameter constraints. But it
adds complexity, too.

Looking forward to your feedback,

--Gunnar

[1] https://github.com/hibernate/hibernate-validator/pull/592
[2] https://github.com/beanvalidation/beanvalidation-spec/pull/116

From gunnar at hibernate.org  Fri Dec 23 05:28:11 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 23 Dec 2016 11:28:11 +0100
Subject: [bv-dev] Happy Holidays and State of the Union
Message-ID: <CADGJaX9os7kbQoTdZ6fm7eNTvQjw3Nw6+d12n5nYmMH8LjWf2Q@mail.gmail.com>

Hi,

As the year's end is approaching, I'd like to wish everyone Happy
Holidays and a great year 2017! I hope you can relax a bit during the
holidays and have a great time with your loved ones.

Also let me say a big "thank you" for all your contributions to Bean
Validation 2.0; all the proposals, discussions, reviews etc. have been
very valuable and are appreciated very much. I think we've made some
good progress already, with some easy wins already merged and more
complex matters such as type-level constraints having advanced quite a
bit.

While waiting for some more feedback on the latest revision of the
extractor proposal [1], I'm finally getting back to the proposal for
java.time support. The API change has already been merged, the RI will
follow closely and you can expect a pull request for the spec update
very soon.

With these two things (value extractors, java.time support) in place
at least in some preliminary form, I think we are in good shape for a
first preview release of the spec. Is there anything missing that you
think should absolutely be in the first preview? My goal is to do the
release early in January. I hope we can get some feedback from the
wider community based on this.

Subsequently, we should pick up some other loose ends such as the
validateValues() idea (BVAL-214) and other things like constraint
ordering (BVAL-248), separation of message interpolation and message
bundle retrieval (BVAL-217) and more.

All, thanks again for your efforts with this spec. I'm looking forward
to making BV 2.0 happen together with you in 2017!

--Gunnar

[1] http://lists.jboss.org/pipermail/beanvalidation-dev/2016-December/001140.html

From christian at kaltepoth.de  Sat Dec 31 11:35:07 2016
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Sat, 31 Dec 2016 17:35:07 +0100
Subject: [bv-dev] Happy Holidays and State of the Union
In-Reply-To: <CADGJaX9os7kbQoTdZ6fm7eNTvQjw3Nw6+d12n5nYmMH8LjWf2Q@mail.gmail.com>
References: <CADGJaX9os7kbQoTdZ6fm7eNTvQjw3Nw6+d12n5nYmMH8LjWf2Q@mail.gmail.com>
Message-ID: <CAEXeC6y_TzwvTTmzFRAaFAuOa+AgAULCCCDHNJW4YAEBiWAQkg@mail.gmail.com>

Hey Gunnar,

thank you very much for these kind words. I would also like to thank you
and everyone else in the EG for the great work. Keep up the good work
everyone! :-)

Christian

2016-12-23 11:28 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> Hi,
>
> As the year's end is approaching, I'd like to wish everyone Happy
> Holidays and a great year 2017! I hope you can relax a bit during the
> holidays and have a great time with your loved ones.
>
> Also let me say a big "thank you" for all your contributions to Bean
> Validation 2.0; all the proposals, discussions, reviews etc. have been
> very valuable and are appreciated very much. I think we've made some
> good progress already, with some easy wins already merged and more
> complex matters such as type-level constraints having advanced quite a
> bit.
>
> While waiting for some more feedback on the latest revision of the
> extractor proposal [1], I'm finally getting back to the proposal for
> java.time support. The API change has already been merged, the RI will
> follow closely and you can expect a pull request for the spec update
> very soon.
>
> With these two things (value extractors, java.time support) in place
> at least in some preliminary form, I think we are in good shape for a
> first preview release of the spec. Is there anything missing that you
> think should absolutely be in the first preview? My goal is to do the
> release early in January. I hope we can get some feedback from the
> wider community based on this.
>
> Subsequently, we should pick up some other loose ends such as the
> validateValues() idea (BVAL-214) and other things like constraint
> ordering (BVAL-248), separation of message interpolation and message
> bundle retrieval (BVAL-217) and more.
>
> All, thanks again for your efforts with this spec. I'm looking forward
> to making BV 2.0 happen together with you in 2017!
>
> --Gunnar
>
> [1] http://lists.jboss.org/pipermail/beanvalidation-dev/
> 2016-December/001140.html
> _______________________________________________
> 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/20161231/121e9fe0/attachment.html