From hendrik.ebbers at me.com Mon Jan 2 17:13:04 2017 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Mon, 02 Jan 2017 23:13:04 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: Hi all & a happy new year! I received a first sketch for the JSR logo (final version will be vector based). What do you think? Cheers, Hendrik > Am 31.12.2016 um 17:35 schrieb Christian Kaltepoth : > > 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 >: > 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 > > _______________________________________________ > 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/20170102/a788a522/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: jbv_scribble_1.jpg Type: image/jpeg Size: 46334 bytes Desc: not available Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170102/a788a522/attachment-0001.jpg From emmanuel at hibernate.org Tue Jan 3 11:23:40 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 3 Jan 2017 17:23:40 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: <20170103162340.GB55138@hibernate.org> It captures nicely Bean Validation. I like it :) On Mon 17-01-02 23:13, Hendrik Ebbers wrote: >Hi all & a happy new year! > >I received a first sketch for the JSR logo (final version will be vector based). What do you think? > >Cheers, > >Hendrik > > > > >> Am 31.12.2016 um 17:35 schrieb Christian Kaltepoth : >> >> 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 >: >> 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 >> >> _______________________________________________ >> 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 christian at kaltepoth.de Tue Jan 3 12:00:43 2017 From: christian at kaltepoth.de (Christian Kaltepoth) Date: Tue, 3 Jan 2017 18:00:43 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: Hendrik, I love your sketch of the logo. It looks great! Thanks for working on it! Christian 2017-01-02 23:13 GMT+01:00 Hendrik Ebbers : > Hi all & a happy new year! > > I received a first sketch for the JSR logo (final version will be vector > based). What do you think? > > Cheers, > > Hendrik > > > > Am 31.12.2016 um 17:35 schrieb Christian Kaltepoth >: > > 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 : > >> 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 > > _______________________________________________ > 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/20170103/cab1a559/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: jbv_scribble_1.jpg Type: image/jpeg Size: 46334 bytes Desc: not available Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170103/cab1a559/attachment-0001.jpg From hendrik.ebbers at me.com Tue Jan 3 12:28:32 2017 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Tue, 03 Jan 2017 18:28:32 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: THX, but I haven't done the sketch ;) A designer made it. If you all like it I will order a vector based logo. Von meinem iPhone gesendet > Am 03.01.2017 um 18:00 schrieb Christian Kaltepoth : > > Hendrik, > > I love your sketch of the logo. It looks great! Thanks for working on it! > > Christian > > > > 2017-01-02 23:13 GMT+01:00 Hendrik Ebbers : >> Hi all & a happy new year! >> >> I received a first sketch for the JSR logo (final version will be vector based). What do you think? >> >> Cheers, >> >> Hendrik >> >> >> >> >>> Am 31.12.2016 um 17:35 schrieb Christian Kaltepoth : >>> >>> 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 : >>>> 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 >>> >>> _______________________________________________ >>> 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/20170103/2731ec0b/attachment.html From gunnar.morling at googlemail.com Tue Jan 3 12:44:46 2017 From: gunnar.morling at googlemail.com (Gunnar Morling) Date: Tue, 3 Jan 2017 18:44:46 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: Yes, it is awesome, absolutely love it. Kudos to your friend and you for making this happen! Am 03.01.2017 6:28 nachm. schrieb "Hendrik Ebbers" : > THX, but I haven't done the sketch ;) A designer made it. If you all like > it I will order a vector based logo. > > Von meinem iPhone gesendet > > Am 03.01.2017 um 18:00 schrieb Christian Kaltepoth >: > > Hendrik, > > I love your sketch of the logo. It looks great! Thanks for working on it! > > Christian > > > > 2017-01-02 23:13 GMT+01:00 Hendrik Ebbers : > >> Hi all & a happy new year! >> >> I received a first sketch for the JSR logo (final version will be vector >> based). What do you think? >> >> Cheers, >> >> Hendrik >> >> >> >> >> Am 31.12.2016 um 17:35 schrieb Christian Kaltepoth < >> christian at kaltepoth.de>: >> >> 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 : >> >>> 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-Dec >>> ember/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 >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170103/f6d58cb5/attachment-0001.html From guillaume.smet at gmail.com Thu Jan 5 11:58:06 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 5 Jan 2017 17:58:06 +0100 Subject: [bv-dev] Improved java.time support follow-up Message-ID: Hi and happy new year to everyone! We discussed a couple of things today with Gunnar and we have a couple of questions for you all regarding the improved java.time support we committed before the holidays. 1. Support for partials ================ The initial proposal of Michael included the support for partials such as YearMonth or MonthDay (ie types which do not strictly represent a point in time). While @Past and @Future make sense for YearMonth, it's a bit more difficult to define them for MonthDay. The implementation we committed indeed supports MonthDay by building a MonthDay from the Clock provided by the ClockProvider and comparing them using MonthDay.compare(...). We tried to think of a use case but couldn't think of any. Partials currently supported are: - LocalTime - MonthDay - OffsetTime - Year - YearMonth I think Year and YearMonth can be considered OK without further discussion. LocalTime and OffsetTime, I can think of use cases. MonthDay, well, I didn't find any potential use case and it looks just weird. That being said, it does not cost us anything to have it for consistency. So, any thoughts on this? Use cases, votes for removing it/keeping it? 2. Resolution ========== In the comments of https://hibernate.atlassian.net/browse/HV-820, someone suggested the idea of resolution. You could have something like: @Future(resolution = ChronoUnit.MONTHS) private LocalDate paymentDate; This would truncate the LocalDates to ChronoUnit.MONTHS before doing the comparison, ensuring that the date should be at least next month. It might also be useful to reduce the resolution of ZonedDateTimes to days before doing the comparison, especially when using the orPresent option. Note that it's only useful if you use a type more precise than what you require for the validation so it might be a very narrow use case not worth adding additional complexity to the standard constraints. Do you see any use cases for that? Have you ever used custom constraints for that? 3. orPresent ========= The current implementation adds orPresent support as an option of the preexisting @Past/@Future annotations: @Past(orPresent = true) / @Future(orPresent = true) Gunnar suggested this afternoon that it might be more readable to have @PastOrPresent/@FutureOrPresent, especially if we have more than one options for @Past/@Future. Something like @Past(resolution = DAY, orPresent = true) would be less readable than @PastOrPresent(resolution = DAY). Personally, I prefer having one annotation with an option rather than 2 different annotations - I think it has a better semantic - but I can see the rationale behind Gunnar's proposal. Thoughts? Thanks. -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170105/3e9416b9/attachment.html From misterm at gmail.com Thu Jan 5 13:17:26 2017 From: misterm at gmail.com (Michael Nascimento) Date: Thu, 5 Jan 2017 16:17:26 -0200 Subject: [bv-dev] Improved java.time support follow-up In-Reply-To: References: Message-ID: Hi Guillaume, Let me see if I can help: On Thu, Jan 5, 2017 at 2:58 PM, Guillaume Smet wrote: > 1. Support for partials > ================ > > The initial proposal of Michael included the support for partials such as > YearMonth or MonthDay (ie types which do not strictly represent a point in > time). > > While @Past and @Future make sense for YearMonth, it's a bit more > difficult to define them for MonthDay. > > The implementation we committed indeed supports MonthDay by building a > MonthDay from the Clock provided by the ClockProvider and comparing them > using MonthDay.compare(...). > > We tried to think of a use case but couldn't think of any. > When you are using a calendar year for fiscal purposes (in Brazil, its January-December), you could use MonthDay to represent a point in time separately from the year. If a MonthDay represents a holiday, there might be other use cases related to the current year. > > That being said, it does not cost us anything to have it for consistency. > Consistency for me is a good argument in itself. If we couldn't think of the use case, maybe it's just because we're temporarily blind. Being consistent doesn't hurt, especially given the effort is minimum :-) > 2. Resolution > ========== > > In the comments of https://hibernate.atlassian.net/browse/HV-820, someone > suggested the idea of resolution. > > You could have something like: > > @Future(resolution = ChronoUnit.MONTHS) > private LocalDate paymentDate; > > This would truncate the LocalDates to ChronoUnit.MONTHS before doing the > comparison, ensuring that the date should be at least next month. > While this is a valid use case, it seems a little bit specific to me in the sense you have a reference for "now" as a comparison (a use case I mentioned before is validating a temporal object against an arbitrary reference) and in this case converting it. This also limits the "truncation" (which is just a specific case of conversion) to ChronoUnit, when other types of conversion might be needed. This can be handled by doing: @Future private YearMonth paymentYearMonth() { return YearMonth.from(paymentDate); } Which is trivial. A more interesting use case that remains unsupported, of which the previous is kind of a specialization is: I have a startDate and an endDate and there is no simple way to express that endDate must be greater or equal than startDate. That would apply to any Comparable, by the way :-( If we are to pursue something more advanced, that's the use case I'd suggest going after. > Note that it's only useful if you use a type more precise than what you > require for the validation so it might be a very narrow use case not worth > adding additional complexity to the standard constraints. > That's my opinion, too narrow. A broader one is relative comparable validation. > 3. orPresent > ========= > > The current implementation adds orPresent support as an option of the > preexisting @Past/@Future annotations: > @Past(orPresent = true) / @Future(orPresent = true) > > Gunnar suggested this afternoon that it might be more readable to have > @PastOrPresent/@FutureOrPresent, especially if we have more than one > options for @Past/@Future. > > Something like @Past(resolution = DAY, orPresent = true) would be less > readable than @PastOrPresent(resolution = DAY). > > Personally, I prefer having one annotation with an option rather than 2 > different annotations - I think it has a better semantic - but I can see > the rationale behind Gunnar's proposal. > I vote for one annotation. PS: sorry for my long absence. My work load got too intense these days, I hope it will cool off soon... Regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170105/e99aa1a7/attachment.html From gunnar at hibernate.org Fri Jan 6 10:43:02 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 6 Jan 2017 16:43:02 +0100 Subject: [bv-dev] Updated proposal for container value extraction In-Reply-To: References: Message-ID: Hi all, I've pushed the consolidated proposal on the validation of container elements as an appendix to the spec draft now: http://beanvalidation.org/latest-draft/spec/#appendix-value-extraction Can you please give it a read and raise your opinion on it. I know that Hendrik and Christian had some remarks/concerns originally, I'd hope the new one can address them appropriately. Apart from the more formal specification I recommend you take a look at the examples [1] to get a feeling for the indented semantics. Towards the end of the appendix there's a list of open questions [2]. Any input on those is highly welcome. E.g. 1, 2 and 5 would deserve some more opinions. Also what's your take on the ValueExtractor API in general? I'll wait a few more days to let you form some thoughts and then start a specific thread per open question. In the meantime we'll continue with implementing this proposal in the RI as far as it's defined. Thanks, --Gunnar [1] http://beanvalidation.org/latest-draft/spec/#_examples_11 [2] http://beanvalidation.org/latest-draft/spec/#_open_questions 2016-12-22 17:15 GMT+01:00 Gunnar Morling : > 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170106/74eafb2d/attachment-0001.html From christian at kaltepoth.de Sun Jan 8 06:43:50 2017 From: christian at kaltepoth.de (Christian Kaltepoth) Date: Sun, 8 Jan 2017 12:43:50 +0100 Subject: [bv-dev] Improved java.time support follow-up In-Reply-To: References: Message-ID: Hey all, see my thoughts inline.. 1. Support for partials >> ================ >> > > [....] >> >> We tried to think of a use case but couldn't think of any. >> > > When you are using a calendar year for fiscal purposes (in Brazil, its > January-December), you could use MonthDay to represent a point in time > separately from the year. If a MonthDay represents a holiday, there might > be other use cases related to the current year. > >> >> That being said, it does not cost us anything to have it for consistency. >> > > Consistency for me is a good argument in itself. If we couldn't think of > the use case, maybe it's just because we're temporarily blind. Being > consistent doesn't hurt, especially given the effort is minimum :-) > I agree with Michael. I could imagine use cases especially in the context of financials (just think of a fiscal year for example). So I would prefer to be consistent and just support it. > 2. Resolution >> ========== >> [...] >> >> This would truncate the LocalDates to ChronoUnit.MONTHS before doing the >> comparison, ensuring that the date should be at least next month. >> >> > While this is a valid use case, it seems a little bit specific to me in > the sense you have a reference for "now" as a comparison (a use case I > mentioned before is validating a temporal object against an arbitrary > reference) and in this case converting it. This also limits the > "truncation" (which is just a specific case of conversion) to ChronoUnit, > when other types of conversion might be needed. > I don't think this is a very common use case. So I currently don't see a good reason to support it. But may be I'm missing a common use case here? > > >> 3. orPresent >> ========= >> [...] >> >> Personally, I prefer having one annotation with an option rather than 2 >> different annotations - I think it has a better semantic - but I can see >> the rationale behind Gunnar's proposal. >> > > I vote for one annotation. > I would also prefer one annotation. I think even something like @Past(resolution = DAY, orPresent = true) is quite good readable. Christian -- 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/20170108/24b8b9dc/attachment.html From gunnar at hibernate.org Tue Jan 10 03:12:58 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 10 Jan 2017 09:12:58 +0100 Subject: [bv-dev] Improved java.time support follow-up In-Reply-To: References: Message-ID: Thanks a lot for your feedback! On 1., I was initially a bit skeptical about @Future for partial types such as LocalTime or MonthDay, which don't denote "one point in time" but a recurring one. But after playing a bit with those types in the RI, having support for them felt alright. On 2., agreed. People can always put their constraint to a derived member with the right resolution as pointed out by Michael, so I don't think it warrants explicit support. On 3., ok, works for me. Based on this feedback and the original proposal [1]. I've sent a pull request for updating the spec (https://github.com/ beanvalidation/beanvalidation-spec/pull/122). Note that you need to take a look at the API project, too, in order to get the full picture (as we include API types directly from there). Any comments on this change are welcome. I'll leave the PR open until the end of the week end then merge it if nothing more comes up. This change does not include support for range data types, I've opened BVAL-553 [2] for that one. @Michael, maybe you are up for writing a proposal for that one, too? Thanks, --Gunnar [1] http://beanvalidation.org/proposals/BVAL-496/ [2] https://hibernate.atlassian.net/browse/BVAL-553 2017-01-08 12:43 GMT+01:00 Christian Kaltepoth : > Hey all, > > see my thoughts inline.. > > > 1. Support for partials >>> ================ >>> >> > >> [....] >>> >>> We tried to think of a use case but couldn't think of any. >>> >> >> When you are using a calendar year for fiscal purposes (in Brazil, its >> January-December), you could use MonthDay to represent a point in time >> separately from the year. If a MonthDay represents a holiday, there might >> be other use cases related to the current year. >> >>> >>> That being said, it does not cost us anything to have it for consistency. >>> >> >> Consistency for me is a good argument in itself. If we couldn't think of >> the use case, maybe it's just because we're temporarily blind. Being >> consistent doesn't hurt, especially given the effort is minimum :-) >> > > I agree with Michael. I could imagine use cases especially in the context > of financials (just think of a fiscal year for example). So I would prefer > to be consistent and just support it. > > > >> 2. Resolution >>> ========== >>> [...] >>> >>> This would truncate the LocalDates to ChronoUnit.MONTHS before doing the >>> comparison, ensuring that the date should be at least next month. >>> >>> >> While this is a valid use case, it seems a little bit specific to me in >> the sense you have a reference for "now" as a comparison (a use case I >> mentioned before is validating a temporal object against an arbitrary >> reference) and in this case converting it. This also limits the >> "truncation" (which is just a specific case of conversion) to ChronoUnit, >> when other types of conversion might be needed. >> > > I don't think this is a very common use case. So I currently don't see a > good reason to support it. But may be I'm missing a common use case here? > > > >> >> >>> 3. orPresent >>> ========= >>> [...] >>> >>> Personally, I prefer having one annotation with an option rather than 2 >>> different annotations - I think it has a better semantic - but I can see >>> the rationale behind Gunnar's proposal. >>> >> >> I vote for one annotation. >> > > I would also prefer one annotation. I think even something > like @Past(resolution = DAY, orPresent = true) is quite good readable. > > > Christian > > > -- > 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/20170110/162e1435/attachment.html From gunnar at hibernate.org Tue Jan 10 03:38:30 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 10 Jan 2017 09:38:30 +0100 Subject: [bv-dev] Improved java.time support follow-up In-Reply-To: References: Message-ID: Hi Michael, > A more interesting use case that remains unsupported, of which the previous is kind > of a specialization is: I have a startDate and an endDate and there is no simple way to > express that endDate must be greater or equal than startDate. That would apply to > any Comparable, by the way It's an interesting request, but I'm not sure whether it pulls its weight. We'd probably end up with something looking like that: @Compare( member1 = "dateOfEntry", comparison = ComparisonType.LESS_THAN, member2 = "dateOfCancelation" ) public class Customer { public LocalDateTime dateOfEntry; public LocalDateTime dateOfCancelation; } I find it doesn't read overly well. It feels a bit too much like "programming in annotations" to me. It also raises the question how to retrieve the values for member1 and member2, getter or field? But there are simple ways for implementing your requirement. Using @AssertTrue, you can do it by writing actual, safe Java code: public class Customer { public LocalDateTime dateOfEntry; public LocalDateTime dateOfCancelation; @AssertTrue public boolean isEntryAndCancelationDatesConsistent() { return dateOfEntry.compareTo( dateOfCancelation ) < 0; } } An alternative is the RI's @ScriptAssert. It even discusses your very example in the docs: @ScriptAssert(lang = "jexl", script = "_.startDate < _.endDate", alias = "_") public class CalendarEvent { private Date startDate; private Date endDate; //... } Would either approach help to address your requirements? --Gunnar From guillaume.smet at gmail.com Tue Jan 10 05:46:32 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 10 Jan 2017 11:46:32 +0100 Subject: [bv-dev] Improved java.time support follow-up In-Reply-To: References: Message-ID: Hi, On Tue, Jan 10, 2017 at 9:12 AM, Gunnar Morling wrote: > Based on this feedback and the original proposal [1]. I've sent a pull > request for updating the spec (https://github.com/beanvalida > tion/beanvalidation-spec/pull/122). Note that you need to take a look at > the API project, too, in order to get the full picture (as we include API > types directly from there). > > Any comments on this change are welcome. I'll leave the PR open until the > end of the week end then merge it if nothing more comes up. > I merged this PR by mistake just now but feel free to add comment on it, I'll ajust what needs to be adjusted. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170110/1c9e3f22/attachment.html From gunnar at hibernate.org Wed Jan 11 10:29:02 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 11 Jan 2017 16:29:02 +0100 Subject: [bv-dev] Diff with changes done for Bean Validation 2.0 Message-ID: Hey, Thanks to the help of Guillaume, we now have a way to view the full diff of changes done for the Bean Validation 2.0 spec. You can find the link(s) under "Resources" on http://beanvalidation.org/specification/. This gets you to diffs of an AsciiDoc file containing the full spec, with all sources included. As we pull in actual source files from the beanvalidation-api into the spec, getting the full picture was rather inconvinient before. The GitHub diff view takes a bit to load, I hope it continues to work as the number of changes grows. You also can view the diff locally by running "git diff" on the "spec-full" branch of the beanvalidation-spec repo. Having a coloured diff of the output (HTML) would be a tad nicer, but it's not supported by AsciiDoc currently. If needed, we may experiment with some external HTML diff tools, but I think so far the AsciiDoc diff isn't too bad (after all, AsciiDoc is meant to be human readable by itself). It already helped to find a few glitches that had sneaked in. --Gunnar From mbenson at apache.org Wed Jan 11 11:45:43 2017 From: mbenson at apache.org (Matt Benson) Date: Wed, 11 Jan 2017 10:45:43 -0600 Subject: [bv-dev] Updated proposal for container value extraction In-Reply-To: References: Message-ID: I generally like this; I think the proposal is in quite good shape. My reactions to the open questions: 1. Should nested containers be supported? Given the Optional> example, it's probably a good idea (certainly it adds some complexity, but anything worth doing is worth doing right, as the saying goes). 2. Should @ConstraintsApplyTo be usable per-constraint? Doing such seems like it could be a bit clumsy, but it might be okay if @ConstraintsApplyTo were repeatable and included Class[] constraintTypes() default {} element which, if non-empty, could differentiate which constraints applied to the wrapper vs. the extracted value. 3. Should @ConstraintsApplyTo also be used for tagging extractors triggering "auto-extraction"? I'm not sure I understand this question. Is this referring to classpath scanning, or "inline" specification of extractors? In either case a separate annotation might be warranted, particularly if the annotation is expanded for other reasons (see #2). 4. Should a path node be added for type argument constraints of Optional and similar types? I don't personally feel this is necessary, but I wouldn't oppose it if others strongly desired it. 5. Should value extractors be discoverable via ServiceLoader? I would personally really like to see this be possible. WRT being able to override these, it seems simple enough that value extractors registered programmatically or in validation.xml could preempt any discovered via ServiceLoader. 6. What to return from PropertyDescriptor#getElementClass() if field type does not match method RT? The Javadoc of PropertyDescriptor references "Java Beans." Java Bean properties are defined by method signatures rather than fields, so it seems an easy decision to choose the method RT over the field signature. 7. Should the presence of type argument constraints alone trigger nested validation? I can appreciate the sense of the consistency argument to requiring @Valid, but in practice it seems reasonable to me that @Valid be implied. It probably would be much simpler to require @Valid from an implementation perspective, however. 8. The core question seems to me to be whether there should be multiple valid mechanisms for specifying constraints on wrapped elements. Since it's necessary to support the inverse for wrapped elements of non-parameterized types, the effort required to support this is probably similar to that required to disallow it. 9. Should we allow extractors to be defined for specific parameterized types? It's tempting to support this, extends bounds and all, just to feel that the feature is as complete as possible. At the same time I can't make a compelling case why such a feature would really be *necessary*. This suggests support for things like: class FooToBarMapValueExtractor implements ValueExtractor> . In this case it might even be reasonable to equivalently support: class FToBMapValueExtractor implements ValueExtractor> (i.e. BV would not care whether the bounds are specified on the type parameter of the extractor class or on the argument to the wrapper type). Not to say that these might not be valid use cases, but we should enter any such complexity with our eyes open, to be sure. 10. I have no suggestions for alternatives to "type argument constraints." "Type constraints" suggests the argument to a type parameter itself. "Type use constraints" is fine with me, though. If people don't know, they can learn. ;) 11. No input on this from me (for now, anyway). 12. I don't see why it would be necessary for an extractor to refer to a parameter from a super type. The super type parameter can(/should) be mapped to a type parameter from the extractor type. Or am I missing something? 13/14. I am in favor of the variant proposals that would permit the type parameter to be included as part of a Path node. Additional notes: * I think we ought to consider whether to provide ValueReceiver methods that omit the nodeName parameter rather than having ValueExtractor implementations pass null. We could potentially then require non-blank values when the nodeName-bearing method variants are called. This would make the API more explicit and we're not talking about an interface that will conceivably have a lot of implementations. * Some of the features that might come under debate, e.g. ServiceLoader-discovered ValueExtractors, could be enabled via implementation-specific configuration parameters or e.g. CDI extensions, etc., if the community can't reach a consensus or decides to omit them. Matt On Fri, Jan 6, 2017 at 9:43 AM, Gunnar Morling wrote: > Hi all, > > I've pushed the consolidated proposal on the validation of container > elements as an appendix to the spec draft now: > > http://beanvalidation.org/latest-draft/spec/#appendix-value-extraction > > Can you please give it a read and raise your opinion on it. I know that > Hendrik and Christian had some remarks/concerns originally, I'd hope the > new one can address them appropriately. Apart from the more formal > specification I recommend you take a look at the examples [1] to get a > feeling for the indented semantics. > > Towards the end of the appendix there's a list of open questions [2]. Any > input on those is highly welcome. E.g. 1, 2 and 5 would deserve some more > opinions. Also what's your take on the ValueExtractor API in general? I'll > wait a few more days to let you form some thoughts and then start a > specific thread per open question. > > In the meantime we'll continue with implementing this proposal in the RI > as far as it's defined. > > Thanks, > > --Gunnar > > [1] http://beanvalidation.org/latest-draft/spec/#_examples_11 > [2] http://beanvalidation.org/latest-draft/spec/#_open_questions > > > > > > 2016-12-22 17:15 GMT+01:00 Gunnar Morling : > >> 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> 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 >> > > > _______________________________________________ > 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/20170111/fb34bb28/attachment-0001.html From emmanuel at hibernate.org Thu Jan 12 10:15:09 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 12 Jan 2017 16:15:09 +0100 Subject: [bv-dev] Updated proposal for container value extraction In-Reply-To: References: Message-ID: Hey, thanks for the feedback Matt > On 11 Jan 2017, at 17:45, Matt Benson wrote: > > I generally like this; I think the proposal is in quite good shape. My reactions to the open questions: > > 1. Should nested containers be supported? > Given the Optional> example, it's probably a good idea (certainly it adds some complexity, but anything worth doing is worth doing right, as the saying goes). > > 2. Should @ConstraintsApplyTo be usable per-constraint? > Doing such seems like it could be a bit clumsy, but it might be okay if @ConstraintsApplyTo were repeatable and included Class[] constraintTypes() default {} element which, if non-empty, could differentiate which constraints applied to the wrapper vs. the extracted value. Do you mean? @ConstraintAppliesTo(target=WRAPPED_VALUE, constraintTypes=Min.class) @Min(3) List nicknames; This approach cannot cover a case were the Min constraint it used one for the container and one for the wrapped value. But it makes me think that we sorta addresssed a similar class of problem with groups. I haven?t explored at all but could we something similar by subverting groups. Let?s define two special groups: OnContainer OnWrappedValue @Min(value3, groups=OnWrappedValue.class) List nicknames; // note that these examples are simplifications and should really be written List<@Min String> nicknames; // but pretend we have a subclass of List with no way to put a TYPE_USE constraint This proposal would not address the case of multiple nestsed containers List> > > 3. Should @ConstraintsApplyTo also be used for tagging extractors triggering "auto-extraction"? > I'm not sure I understand this question. Is this referring to classpath scanning, or "inline" specification of extractors? In either case a separate annotation might be warranted, particularly if the annotation is expanded for other reasons (see #2). No it?s to define that a given extractor prefers to target the wrapped value vs targeting the container @ConstraintsApplyTo(WRAPPED_VALUE) class OptionalExtractor ? {} @Min(2) Optional foo; // equivalent to @Min @ConstraintsApplyTo(WRAPPED_VALUE) Optional foo; This behavior is hardcoded for Optional in the spec for info. > > 4. Should a path node be added for type argument constraints of Optional and similar types? > I don't personally feel this is necessary, but I wouldn't oppose it if others strongly desired it. > > 5. Should value extractors be discoverable via ServiceLoader? > I would personally really like to see this be possible. WRT being able to override these, it seems simple enough that value extractors registered programmatically or in validation.xml could preempt any discovered via ServiceLoader. > > 6. What to return from PropertyDescriptor#getElementClass() if field type does not match method RT? > The Javadoc of PropertyDescriptor references "Java Beans." Java Bean properties are defined by method signatures rather than fields, so it seems an easy decision to choose the method RT over the field signature. > > 7. Should the presence of type argument constraints alone trigger nested validation? > I can appreciate the sense of the consistency argument to requiring @Valid, but in practice it seems reasonable to me that @Valid be implied. It probably would be much simpler to require @Valid from an implementation perspective, however. I personally am a bit reluctant. Do we really think that this is the default behavior people will want? Because you cannot negate a @Valid today so that?s a definitive decision. It seems to be that many containers are not beans per se and don?t want their properties to be validated, just the extacted stuff,. [more reading later] From mbenson at apache.org Thu Jan 12 13:45:04 2017 From: mbenson at apache.org (Matt Benson) Date: Thu, 12 Jan 2017 12:45:04 -0600 Subject: [bv-dev] Updated proposal for container value extraction In-Reply-To: References: Message-ID: On Thu, Jan 12, 2017 at 9:15 AM, Emmanuel Bernard wrote: > Hey, thanks for the feedback Matt > > > On 11 Jan 2017, at 17:45, Matt Benson wrote: > > > > I generally like this; I think the proposal is in quite good shape. My > reactions to the open questions: > > > > 1. Should nested containers be supported? > > Given the Optional> example, it's probably a good > idea (certainly it adds some complexity, but anything worth doing is worth > doing right, as the saying goes). > > > > 2. Should @ConstraintsApplyTo be usable per-constraint? > > Doing such seems like it could be a bit clumsy, but it might be okay > if @ConstraintsApplyTo were repeatable and included Class Annotation>[] constraintTypes() default {} element which, if non-empty, > could differentiate which constraints applied to the wrapper vs. the > extracted value. > > Do you mean? > > @ConstraintAppliesTo(target=WRAPPED_VALUE, constraintTypes=Min.class) > @Min(3) > List nicknames; > > This approach cannot cover a case were the Min constraint it used one for > the container and one for the wrapped value. > That is what I was postulating, yes. Min might not be the best example. NotNull might be a better example of a constraint that one would want to apply both to the wrapper and the extracted value. > > But it makes me think that we sorta addresssed a similar class of problem > with groups. > I haven?t explored at all but could we something similar by subverting > groups. Let?s define two special groups: OnContainer OnWrappedValue > > @Min(value3, groups=OnWrappedValue.class) > List nicknames; > // note that these examples are simplifications and should really be > written List<@Min String> nicknames; > // but pretend we have a subclass of List with no way to put a > TYPE_USE constraint > > The idea is kind of cute (for lack of a better word), but doesn't this complicate or prevent "normal" use of validation groups? > This proposal would not address the case of multiple nestsed containers > List> > > I agree that specifying WRAPPED_VALUE per-property is ambiguous for List>. Maybe that is an argument against allowing #8. What if the rule were that @ConstraintsApplyTo(WRAPPED_VALUE) is valid on TypeExtractor class definitions, while @ConstraintsApplyTo(ANNOTATED_ELEMENT) is valid elsewhere, serving only to override the behavior specified by the extractor? Then you could have @Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List> . This still doesn't solve #2, but I think the problems are orthogonal. > > > > 3. Should @ConstraintsApplyTo also be used for tagging extractors > triggering "auto-extraction"? > > I'm not sure I understand this question. Is this referring to > classpath scanning, or "inline" specification of extractors? In either case > a separate annotation might be warranted, particularly if the annotation is > expanded for other reasons (see #2). > > No it?s to define that a given extractor prefers to target the wrapped > value vs targeting the container > > @ConstraintsApplyTo(WRAPPED_VALUE) > class OptionalExtractor ? {} > > @Min(2) Optional foo; > // equivalent to @Min @ConstraintsApplyTo(WRAPPED_VALUE) Optional > foo; > > This behavior is hardcoded for Optional in the spec for info. > > Are you saying that question #3 is just asking for validation of this idea as outlined in the current draft? Then my answer is yes. > > > > 4. Should a path node be added for type argument constraints of Optional > and similar types? > > I don't personally feel this is necessary, but I wouldn't oppose it if > others strongly desired it. > > > > 5. Should value extractors be discoverable via ServiceLoader? > > I would personally really like to see this be possible. WRT being able > to override these, it seems simple enough that value extractors registered > programmatically or in validation.xml could preempt any discovered via > ServiceLoader. > > > > 6. What to return from PropertyDescriptor#getElementClass() if field > type does not match method RT? > > The Javadoc of PropertyDescriptor references "Java Beans." Java Bean > properties are defined by method signatures rather than fields, so it seems > an easy decision to choose the method RT over the field signature. > > > > 7. Should the presence of type argument constraints alone trigger nested > validation? > > I can appreciate the sense of the consistency argument to requiring > @Valid, but in practice it seems reasonable to me that @Valid be implied. > It probably would be much simpler to require @Valid from an implementation > perspective, however. > > I personally am a bit reluctant. Do we really think that this is the > default behavior people will want? Because you cannot negate a @Valid today > so that?s a definitive decision. It seems to be that many containers are > not beans per se and don?t want their properties to be validated, just the > extacted stuff,. > > Are you saying that type argument constraints will be validated using extraction, but that only validation of the Map object *itself* would depend on @Valid to trigger validation of Map values per BV 1.x? So if Address had validation metadata, you could have: Map And BV would validate that the values were non-null, but would not invoke Address validation without @Valid on the Map (BV 1.x) or on the Address type parameter? That makes sense to me. You could then combine: Map Matt > [more reading later] > > > _______________________________________________ > 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/20170112/d27faf3b/attachment.html From emmanuel at hibernate.org Fri Jan 13 03:04:57 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 13 Jan 2017 09:04:57 +0100 Subject: [bv-dev] Updated proposal for container value extraction In-Reply-To: References: Message-ID: <63D8C7D1-18FF-4D62-A955-DF588021C041@hibernate.org> > On 12 Jan 2017, at 19:45, Matt Benson wrote: > > 2. Should @ConstraintsApplyTo be usable per-constraint? > > Doing such seems like it could be a bit clumsy, but it might be okay if @ConstraintsApplyTo were repeatable and included Class[] constraintTypes() default {} element which, if non-empty, could differentiate which constraints applied to the wrapper vs. the extracted value. > > Do you mean? > > @ConstraintAppliesTo(target=WRAPPED_VALUE, constraintTypes=Min.class) > @Min(3) > List nicknames; > > This approach cannot cover a case were the Min constraint it used one for the container and one for the wrapped value. > > That is what I was postulating, yes. Min might not be the best example. NotNull might be a better example of a constraint that one would want to apply both to the wrapper and the extracted value. In this case, let?s use @Size whbich would make the example valid. A list of at least 3 elements vs a nickname of at least 3 characters. > > But it makes me think that we sorta addresssed a similar class of problem with groups. > I haven?t explored at all but could we something similar by subverting groups. Let?s define two special groups: OnContainer OnWrappedValue > > @Min(value3, groups=OnWrappedValue.class) > List nicknames; > // note that these examples are simplifications and should really be written List<@Min String> nicknames; > // but pretend we have a subclass of List with no way to put a TYPE_USE constraint > > > The idea is kind of cute (for lack of a better word), but doesn't this complicate or prevent "normal" use of validation groups? Right, it needs to be explored enough to qualify or be rejected. I * think* that since groups are additive in nature and if we disallow people to use these special groups in sequences and other groups, they would not interfere at all. > > This proposal would not address the case of multiple nestsed containers List> > > > I agree that specifying WRAPPED_VALUE per-property is ambiguous for List>. Maybe that is an argument against allowing #8. What if the rule were that @ConstraintsApplyTo(WRAPPED_VALUE) is valid on TypeExtractor class definitions, while @ConstraintsApplyTo(ANNOTATED_ELEMENT) is valid elsewhere, serving only to override the behavior specified by the extractor? Then you could have @Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List> . This still doesn't solve #2, but I think the problems are orthogonal. I suppose this assumes that most if not all extractor would have @ConstraintsApplyTo(WRAPPED_VALUE) set so that a user has the option to do annotated element vs wrapped value on site. That would be a bad default for iterable and break BV 1.1 semantic in a backward incompatible way (without @ConstraintsApplyTo on site, my @Min annotation would not longer validate the container size but what?s inside. Plus the example you give is just bad practice and illogical to quote Spok. @Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List> If you can plance constraints where you want, place then where they are the more natural and in this case the example is rewritten @Size(min=5) List<@Size(min=3) List<@Size(min=3) String>> The problema rises when you have class Matrix extends List> {} You have no place to put @Size(min=3) and @Size(min=24) @Size(min=5) @Size(min=3) //I want to be in the inner list @Size(min=24) // I want to be in the most inner wrapped element Matrix matrix; TODO: I think I?m fine with not supporting such case and support #8 personally. > > > 7. Should the presence of type argument constraints alone trigger nested validation? > > I can appreciate the sense of the consistency argument to requiring @Valid, but in practice it seems reasonable to me that @Valid be implied. It probably would be much simpler to require @Valid from an implementation perspective, however. > > I personally am a bit reluctant. Do we really think that this is the default behavior people will want? Because you cannot negate a @Valid today so that?s a definitive decision. It seems to be that many containers are not beans per se and don?t want their properties to be validated, just the extacted stuff,. > > Are you saying that type argument constraints will be validated using extraction, but that only validation of the Map object *itself* would depend on @Valid to trigger validation of Map values per BV 1.x? So if Address had validation metadata, you could have: > > Map > > And BV would validate that the values were non-null, but would not invoke Address validation without @Valid on the Map (BV 1.x) or on the Address type parameter? That makes sense to me. You could then combine: > > Map Your understanding is correct, to validate the properties of Address, you need the @Valid annotation. What the question 7 is about though is a bit different, I think (I?m confused now too :) ) Assume the following container class class Tuple { @NotNull T1 getT1(); @Min(3) getSize(); ... } Does the following validate that Integer is not null, does it validate that tuple size is at least 3? Tuple<@Min(1) Integer, @Email String> tuple; Is that a fair understanding of the question Gunnar ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/69c88f55/attachment-0001.html From emmanuel at hibernate.org Fri Jan 13 03:06:05 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 13 Jan 2017 09:06:05 +0100 Subject: [bv-dev] Updated proposal for container value extraction In-Reply-To: <63D8C7D1-18FF-4D62-A955-DF588021C041@hibernate.org> References: <63D8C7D1-18FF-4D62-A955-DF588021C041@hibernate.org> Message-ID: <44864E69-D3A4-4C5A-B2AA-2B070471DAD5@hibernate.org> > On 13 Jan 2017, at 09:04, Emmanuel Bernard wrote: > > TODO: I think I?m fine with not supporting such case and support #8 personally. Pretend this sentence was never in my email. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/584e1a5f/attachment.html From emmanuel at hibernate.org Fri Jan 13 03:15:47 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 13 Jan 2017 09:15:47 +0100 Subject: [bv-dev] Updated proposal for container value extraction In-Reply-To: References: Message-ID: <1917686F-938B-4A45-8BBD-8E4146A7BAE9@hibernate.org> > 8. The core question seems to me to be whether there should be multiple valid mechanisms for specifying constraints on wrapped elements. > Since it's necessary to support the inverse for wrapped elements of non-parameterized types, the effort required to support this is probably similar to that required to disallow it. Right that?s Gunnar?s argument, it would feel weird to disallow it. My slight preference would be to disallow it for it?s ?wrongness? (it confuses code more than clarifying it). > > 12. I don't see why it would be necessary for an extractor to refer to a parameter from a super type. The super type parameter can(/should) be mapped to a type parameter from the extractor type. Or am I missing something? The feature got introduced at a time where we did need that feature for now deprecated reasons. But there is still a theoretical situation. I have a Map value extractor and a HashMap value extractor. Somehow the HashMap value extractor uses HashMap specific methods to do the extraction job in a more efficient way. But we have not found a concrete example of that problem. From guillaume.smet at gmail.com Fri Jan 13 05:50:15 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 13 Jan 2017 11:50:15 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? Message-ID: Hi, This is the first of a series of threads about the open questions regarding value extraction [1]. We hope having a separate thread per question will help having a more structured and easy to follow discussion. Summary of the issue ================ ConstraintsApplyTo only allows one behavior per annotated element. Should it be per constraint? E.g. for @NotNull @Email StringProperty email it may be desirable to apply @NotNull to the wrapper but @Email to the wrapped value. That?s not possible currently. Summary of the discussions going on ============================ Matt proposed something like: @ConstraintsApplyTo(target=WRAPPED_VALUE, constraintTypes=Size.class) @Size(3) List nicknames; As noted by Emmanuel, it does not solve the issue when you want 2 @Size constraints, one for the List and the other for the enclosed String. Emmanuel proposed to use groups to solve this issue: " But it makes me think that we sorta addresssed a similar class of problem with groups. I haven?t explored at all but could we something similar by subverting groups. Let?s define two special groups: OnContainer OnWrappedValue @Min(value3, groups=OnWrappedValue.class) List nicknames; " [1] http://beanvalidation.org/latest-draft/spec/#_open_questions -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/06193761/attachment.html From guillaume.smet at gmail.com Fri Jan 13 06:12:00 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 13 Jan 2017 12:12:00 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: Message-ID: Hi, I don't think relying on groups is such a good idea. It's already a complicated area and adding some magic groups won't help. Is there something preventing us from doing something like: @Size(3, applyTo = ANNOTATED_ELEMENT) @Size(10, applyTo = WRAPPED_VALUE) ListOfStrings nicknames; ANNOTATED_ELEMENT would be the default and would mean apply the constraint to the currently annotated element. So List<@Size(10) String> would mean apply the constraint to the annotated element so to the String. List<@Size(10, applyTo = WRAPPED_VALUE) Optional> would apply the constraint to the String contained in the Optional. The drawback I can see is that it adds a new reserved method to the @Constraint annotations. To make the migration more smooth, we could make it optional and test the returnType of the method before using the result. -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/8949c25c/attachment.html From guillaume.smet at gmail.com Fri Jan 13 06:22:46 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 13 Jan 2017 12:22:46 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: Message-ID: Hi again, On Fri, Jan 13, 2017 at 12:12 PM, Guillaume Smet wrote: > The drawback I can see is that it adds a new reserved method to the > @Constraint annotations. To make the migration more smooth, we could make > it optional and test the returnType of the method before using the result. > After speaking with Gunnar, we would need a "valid" prefix on the name of the method so something like validationAppliesTo would work: @Size(3, validationAppliesTo = ANNOTATED_ELEMENT) @Size(10, validationAppliesTo = WRAPPED_VALUE) ListOfStrings nicknames; -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/79a46283/attachment.html From gunnar at hibernate.org Fri Jan 13 07:01:55 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 13 Jan 2017 13:01:55 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: Message-ID: Unfortunately, validationAppliesTo() is already taken: http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimplementation-constraintdefinition-validationappliesto It's used to distinguish between return value and cross-parameter constraints. Any other name I can think of right now would make up for much confusion with that option. 2017-01-13 12:22 GMT+01:00 Guillaume Smet : > Hi again, > > On Fri, Jan 13, 2017 at 12:12 PM, Guillaume Smet > wrote: >> >> The drawback I can see is that it adds a new reserved method to the >> @Constraint annotations. To make the migration more smooth, we could make it >> optional and test the returnType of the method before using the result. > > > After speaking with Gunnar, we would need a "valid" prefix on the name of > the method so something like validationAppliesTo would work: > @Size(3, validationAppliesTo = ANNOTATED_ELEMENT) > @Size(10, validationAppliesTo = WRAPPED_VALUE) > ListOfStrings nicknames; > > -- > Guillaume > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From guillaume.smet at gmail.com Fri Jan 13 07:29:05 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 13 Jan 2017 13:29:05 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: Message-ID: On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling wrote: > Unfortunately, validationAppliesTo() is already taken: > http://beanvalidation.org/latest-draft/spec/# > constraintsdefinitionimplementation-constraintdefinition- > validationappliesto > > It's used to distinguish between return value and cross-parameter > constraints. > > Any other name I can think of right now would make up for much > confusion with that option. > Too good to be true :). That being said, I'm wondering if we could reuse it and just add 2 other values to ConstraintTarget. All in all, it's the same concept. The default being IMPLICIT is not too bad either. -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/52c4224a/attachment-0001.html From gunnar at hibernate.org Fri Jan 13 07:38:53 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 13 Jan 2017 13:38:53 +0100 Subject: [bv-dev] Value extraction open issue #7: Should type argument constraints trigger cascaded validation? Message-ID: Should the presence of type argument constraints alone trigger cascaded validation E.g. consider the case of Tuple: class Tuple { @NotNull T1 getT1(); @Min(3) getSize(); // ... } When validating class TupleUser { Tuple<@Min(1) Integer, @Email String> tuple; } should this trigger cascaded validation of "tuple", i.e. validation of @NotNull and @Min within the Tuple class itself? A variation of the issue is Map myMap; where validation of "myMap" would cause validation of @NotNull for the map values, but should it also cause validation of constraints declared on Address? Currently, the sole presence of type argument constraints would not trigger such cascaded validation. You'll need to put @Valid in place to do so: @Valid Tuple<@Min(1) Integer, @Email String> tuple; Map myMap; I found such implicit cascaded validation semi-attractive at some point, but since then have come to think that requiring @Valid is the better alternative, as it's more consistent with the 1.1 behaviour. I *think* Matt and Emmanuel support that @Valid should be required (but confirmation would be nice). What do others think? --Gunnar From guillaume.smet at gmail.com Fri Jan 13 07:53:02 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 13 Jan 2017 13:53:02 +0100 Subject: [bv-dev] Value extraction open issue #7: Should type argument constraints trigger cascaded validation? In-Reply-To: References: Message-ID: Hi, On Fri, Jan 13, 2017 at 1:38 PM, Gunnar Morling wrote: > > I *think* Matt and Emmanuel support that @Valid should be required > (but confirmation would be nice). What do others think? > +1 from me on requiring @Valid. Typically the validation of the bean can be an heavy process and you might not want to trigger it. -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/2899d890/attachment.html From emmanuel at hibernate.org Fri Jan 13 08:48:36 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 13 Jan 2017 14:48:36 +0100 Subject: [bv-dev] Value extraction open issue #7: Should type argument constraints trigger cascaded validation? In-Reply-To: References: Message-ID: > > I *think* Matt and Emmanuel support that @Valid should be required > (but confirmation would be nice). What do others think? Yes I?m in favor of requiring it. From emmanuel at hibernate.org Fri Jan 13 08:58:49 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 13 Jan 2017 14:58:49 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: Message-ID: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> > On 13 Jan 2017, at 13:29, Guillaume Smet wrote: > > On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling > wrote: > Unfortunately, validationAppliesTo() is already taken: > http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimplementation-constraintdefinition-validationappliesto > > It's used to distinguish between return value and cross-parameter constraints. > > Any other name I can think of right now would make up for much > confusion with that option. > > Too good to be true :). > > That being said, I'm wondering if we could reuse it and just add 2 other values to ConstraintTarget. All in all, it's the same concept. The default being IMPLICIT is not too bad either. Right I think it?s worth exploring. I still like my group repurposing trick though even if it offenses the clean camp :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/93867bd3/attachment.html From gunnar at hibernate.org Fri Jan 13 09:22:18 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 13 Jan 2017 15:22:18 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> Message-ID: As a variation of Matt's idea, an optional index() parameter could be added: @Size(1) @Size(3) @ApplyConstraintTo(constraint=Size.class, index=1, target=WRAPPED_VALUE) List nicknames; It could be omitted (via a default value of -1 or similar) if there is only one constraint of the type in question: @NotNull @Email @ApplyConstraintTo(constraint=NotNull.class, target=ANNOTATED_ELEMENT) Optional email; Does the trick, though it's still a tad verbose. 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard : > > On 13 Jan 2017, at 13:29, Guillaume Smet wrote: > > On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling > wrote: >> >> Unfortunately, validationAppliesTo() is already taken: >> >> http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimplementation-constraintdefinition-validationappliesto >> >> It's used to distinguish between return value and cross-parameter >> constraints. >> >> Any other name I can think of right now would make up for much >> confusion with that option. > > > Too good to be true :). > > That being said, I'm wondering if we could reuse it and just add 2 other > values to ConstraintTarget. All in all, it's the same concept. The default > being IMPLICIT is not too bad either. > > > Right I think it?s worth exploring. > I still like my group repurposing trick though even if it offenses the clean > camp :) > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From emmanuel at hibernate.org Fri Jan 13 09:54:57 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 13 Jan 2017 15:54:57 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> Message-ID: <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> I looked at that, and I?m not sure you are guaranteed to get an other. Plus you have this problem @Min @Min.List({@Min, @Min}) @Min BooYahh foo; > On 13 Jan 2017, at 15:22, Gunnar Morling wrote: > > As a variation of Matt's idea, an optional index() parameter could be added: > > @Size(1) > @Size(3) > @ApplyConstraintTo(constraint=Size.class, index=1, target=WRAPPED_VALUE) > List nicknames; > > It could be omitted (via a default value of -1 or similar) if there is > only one constraint of the type in question: > > @NotNull > @Email > @ApplyConstraintTo(constraint=NotNull.class, target=ANNOTATED_ELEMENT) > Optional email; > > Does the trick, though it's still a tad verbose. > > > 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard : >> >> On 13 Jan 2017, at 13:29, Guillaume Smet wrote: >> >> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling >> wrote: >>> >>> Unfortunately, validationAppliesTo() is already taken: >>> >>> http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimplementation-constraintdefinition-validationappliesto >>> >>> It's used to distinguish between return value and cross-parameter >>> constraints. >>> >>> Any other name I can think of right now would make up for much >>> confusion with that option. >> >> >> Too good to be true :). >> >> That being said, I'm wondering if we could reuse it and just add 2 other >> values to ConstraintTarget. All in all, it's the same concept. The default >> being IMPLICIT is not too bad either. >> >> >> Right I think it?s worth exploring. >> I still like my group repurposing trick though even if it offenses the clean >> camp :) >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From emmanuel at hibernate.org Fri Jan 13 09:57:05 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 13 Jan 2017 15:57:05 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> Message-ID: s/other/order from the JVM/ > On 13 Jan 2017, at 15:54, Emmanuel Bernard wrote: > > I looked at that, and I?m not sure you are guaranteed to get an other. > Plus you have this problem > > @Min > @Min.List({@Min, @Min}) > @Min > BooYahh foo; > >> On 13 Jan 2017, at 15:22, Gunnar Morling wrote: >> >> As a variation of Matt's idea, an optional index() parameter could be added: >> >> @Size(1) >> @Size(3) >> @ApplyConstraintTo(constraint=Size.class, index=1, target=WRAPPED_VALUE) >> List nicknames; >> >> It could be omitted (via a default value of -1 or similar) if there is >> only one constraint of the type in question: >> >> @NotNull >> @Email >> @ApplyConstraintTo(constraint=NotNull.class, target=ANNOTATED_ELEMENT) >> Optional email; >> >> Does the trick, though it's still a tad verbose. >> >> >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard : >>> >>> On 13 Jan 2017, at 13:29, Guillaume Smet wrote: >>> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling >>> wrote: >>>> >>>> Unfortunately, validationAppliesTo() is already taken: >>>> >>>> http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimplementation-constraintdefinition-validationappliesto >>>> >>>> It's used to distinguish between return value and cross-parameter >>>> constraints. >>>> >>>> Any other name I can think of right now would make up for much >>>> confusion with that option. >>> >>> >>> Too good to be true :). >>> >>> That being said, I'm wondering if we could reuse it and just add 2 other >>> values to ConstraintTarget. All in all, it's the same concept. The default >>> being IMPLICIT is not too bad either. >>> >>> >>> Right I think it?s worth exploring. >>> I still like my group repurposing trick though even if it offenses the clean >>> camp :) >>> >>> _______________________________________________ >>> beanvalidation-dev mailing list >>> beanvalidation-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From mbenson at apache.org Fri Jan 13 11:06:31 2017 From: mbenson at apache.org (Matt Benson) Date: Fri, 13 Jan 2017 10:06:31 -0600 Subject: [bv-dev] Updated proposal for container value extraction In-Reply-To: <63D8C7D1-18FF-4D62-A955-DF588021C041@hibernate.org> References: <63D8C7D1-18FF-4D62-A955-DF588021C041@hibernate.org> Message-ID: On Fri, Jan 13, 2017 at 2:04 AM, Emmanuel Bernard wrote: > > On 12 Jan 2017, at 19:45, Matt Benson wrote: > >> > 2. Should @ConstraintsApplyTo be usable per-constraint? >> > Doing such seems like it could be a bit clumsy, but it might be okay >> if @ConstraintsApplyTo were repeatable and included Class> Annotation>[] constraintTypes() default {} element which, if non-empty, >> could differentiate which constraints applied to the wrapper vs. the >> extracted value. >> >> Do you mean? >> >> @ConstraintAppliesTo(target=WRAPPED_VALUE, constraintTypes=Min.class) >> @Min(3) >> List nicknames; >> >> This approach cannot cover a case were the Min constraint it used one for >> the container and one for the wrapped value. >> > > That is what I was postulating, yes. Min might not be the best example. > NotNull might be a better example of a constraint that one would want to > apply both to the wrapper and the extracted value. > > > In this case, let?s use @Size whbich would make the example valid. A list > of at least 3 elements vs a nickname of at least 3 characters. > > >> But it makes me think that we sorta addresssed a similar class of problem >> with groups. >> I haven?t explored at all but could we something similar by subverting >> groups. Let?s define two special groups: OnContainer OnWrappedValue >> >> @Min(value3, groups=OnWrappedValue.class) >> List nicknames; >> // note that these examples are simplifications and should really be >> written List<@Min String> nicknames; >> // but pretend we have a subclass of List with no way to put a >> TYPE_USE constraint >> >> > The idea is kind of cute (for lack of a better word), but doesn't this > complicate or prevent "normal" use of validation groups? > > > Right, it needs to be explored enough to qualify or be rejected. > I * think* that since groups are additive in nature and if we disallow > people to use these special groups in sequences and other groups, they > would not interfere at all. > > > >> This proposal would not address the case of multiple nestsed containers >> List> >> >> > I agree that specifying WRAPPED_VALUE per-property is ambiguous for > List>. Maybe that is an argument against allowing #8. What if > the rule were that @ConstraintsApplyTo(WRAPPED_VALUE) is valid on > TypeExtractor class definitions, while @ConstraintsApplyTo(ANNOTATED_ELEMENT) > is valid elsewhere, serving only to override the behavior specified by the > extractor? Then you could have @Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) > List<@Size(min=3) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List> . > This still doesn't solve #2, but I think the problems are orthogonal. > > > I suppose this assumes that most if not all extractor would have > @ConstraintsApplyTo(WRAPPED_VALUE) set so that a user has the option to > do annotated element vs wrapped value on site. That would be a bad default > for iterable and break BV 1.1 semantic in a backward incompatible way > (without @ConstraintsApplyTo on site, my @Min annotation would not longer > validate the container size but what?s inside. > > Plus the example you give is just bad practice and illogical to quote Spok. > Okay, you're right: List was a bad example, since its type parameter should be a "plain" extractor. So let's use Optional, whose extractor is annotated such that constraints apply to wrapped values by default: @NotNull @ConstraintsApplyTo(ANNOTATED_ELEMENT) Optional<@NotNull @ConstraintsApplyTo(ANNOTATED_ELEMENT) Optional> optOptFoo; This invokes question #2, whether there would be a way at the "top" level to declare that neither the outer Optional nor the inner Optional may be null. If so, the above example could be rewritten using that mechanism. Matt > > @Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3) @ > ConstraintsApplyTo(ANNOTATED_ELEMENT) List> > > If you can plance constraints where you want, place then where they are > the more natural and in this case the example is rewritten > > @Size(min=5) List<@Size(min=3) List<@Size(min=3) String>> > > The problema rises when you have class Matrix extends List> {} > You have no place to put @Size(min=3) and @Size(min=24) > > @Size(min=5) > @Size(min=3) //I want to be in the inner list > @Size(min=24) // I want to be in the most inner wrapped element > Matrix matrix; > > TODO: I think I?m fine with not supporting such case and support #8 > personally. > > >> > 7. Should the presence of type argument constraints alone trigger >> nested validation? >> > I can appreciate the sense of the consistency argument to requiring >> @Valid, but in practice it seems reasonable to me that @Valid be implied. >> It probably would be much simpler to require @Valid from an implementation >> perspective, however. >> >> I personally am a bit reluctant. Do we really think that this is the >> default behavior people will want? Because you cannot negate a @Valid today >> so that?s a definitive decision. It seems to be that many containers are >> not beans per se and don?t want their properties to be validated, just the >> extacted stuff,. >> >> Are you saying that type argument constraints will be validated using > extraction, but that only validation of the Map object *itself* would > depend on @Valid to trigger validation of Map values per BV 1.x? So if > Address had validation metadata, you could have: > > Map > > And BV would validate that the values were non-null, but would not invoke > Address validation without @Valid on the Map (BV 1.x) or on the Address > type parameter? That makes sense to me. You could then combine: > > Map > > > Your understanding is correct, to validate the properties of Address, you > need the @Valid annotation. > > What the question 7 is about though is a bit different, I think (I?m > confused now too :) ) > > Assume the following container class > > class Tuple { > > @NotNull > T1 getT1(); > > @Min(3) > getSize(); > > ... > } > > Does the following validate that Integer is not null, does it validate > that tuple size is at least 3? > > Tuple<@Min(1) Integer, @Email String> tuple; > > Is that a fair understanding of the question 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/20170113/740fc94d/attachment.html From mbenson at apache.org Fri Jan 13 11:23:15 2017 From: mbenson at apache.org (Matt Benson) Date: Fri, 13 Jan 2017 10:23:15 -0600 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> Message-ID: On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard wrote: > s/other/order from the JVM/ > > > On 13 Jan 2017, at 15:54, Emmanuel Bernard > wrote: > > > > I looked at that, and I?m not sure you are guaranteed to get an other. > > Plus you have this problem > > > > @Min > > @Min.List({@Min, @Min}) > > @Min > > BooYahh foo; > > > I would have thought the same; however per [1] order is guaranteed. Your additional concern is still there. Maybe it would be cleaner to support this using meta-constraint annotations. > >> On 13 Jan 2017, at 15:22, Gunnar Morling wrote: > >> > >> As a variation of Matt's idea, an optional index() parameter could be > added: > >> > >> @Size(1) > >> @Size(3) > >> @ApplyConstraintTo(constraint=Size.class, index=1, > target=WRAPPED_VALUE) > >> List nicknames; > >> > >> It could be omitted (via a default value of -1 or similar) if there is > >> only one constraint of the type in question: > >> > >> @NotNull > >> @Email > >> @ApplyConstraintTo(constraint=NotNull.class, > target=ANNOTATED_ELEMENT) > >> Optional email; > >> > >> Does the trick, though it's still a tad verbose. > >> > >> > >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard : > >>> > >>> On 13 Jan 2017, at 13:29, Guillaume Smet > wrote: > >>> > >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling > >>> wrote: > >>>> > >>>> Unfortunately, validationAppliesTo() is already taken: > >>>> > >>>> http://beanvalidation.org/latest-draft/spec/# > constraintsdefinitionimplementation-constraintdefinition- > validationappliesto > >>>> > >>>> It's used to distinguish between return value and cross-parameter > >>>> constraints. > >>>> > >>>> Any other name I can think of right now would make up for much > >>>> confusion with that option. > >>> > >>> > >>> Too good to be true :). > >>> > >>> That being said, I'm wondering if we could reuse it and just add 2 > other > >>> values to ConstraintTarget. All in all, it's the same concept. The > default > >>> being IMPLICIT is not too bad either. > >>> > >>> > >>> Right I think it?s worth exploring. > >>> I still like my group repurposing trick though even if it offenses the > clean > >>> camp :) > >>> > I still can't figure out how you would use the group trick in conjunction with validation of a "real" group. Matt [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.5 > >>> _______________________________________________ > >>> beanvalidation-dev mailing list > >>> beanvalidation-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > >> > >> _______________________________________________ > >> beanvalidation-dev mailing list > >> beanvalidation-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > > _______________________________________________ > > beanvalidation-dev mailing list > > beanvalidation-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/3fe54b8b/attachment-0001.html From mbenson at apache.org Fri Jan 13 11:23:55 2017 From: mbenson at apache.org (Matt Benson) Date: Fri, 13 Jan 2017 10:23:55 -0600 Subject: [bv-dev] Value extraction open issue #7: Should type argument constraints trigger cascaded validation? In-Reply-To: References: Message-ID: On Fri, Jan 13, 2017 at 7:48 AM, Emmanuel Bernard wrote: > > > > I *think* Matt and Emmanuel support that @Valid should be required > > (but confirmation would be nice). What do others think? > > Yes I?m in favor of requiring it. > I agree. Matt > _______________________________________________ > 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/20170113/8f0ce8ec/attachment.html From mbenson at apache.org Fri Jan 13 11:39:16 2017 From: mbenson at apache.org (Matt Benson) Date: Fri, 13 Jan 2017 10:39:16 -0600 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> Message-ID: On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson wrote: > > On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard > wrote: > >> s/other/order from the JVM/ >> >> > On 13 Jan 2017, at 15:54, Emmanuel Bernard >> wrote: >> > >> > I looked at that, and I?m not sure you are guaranteed to get an other. >> > Plus you have this problem >> > >> > @Min >> > @Min.List({@Min, @Min}) >> > @Min >> > BooYahh foo; >> > >> > > I would have thought the same; however per [1] order is guaranteed. Your > additional concern is still there. Maybe it would be cleaner to support > this using meta-constraint annotations. > Actually, per the same section of the JLS, your example is referred to as "obtuse" (which I'm sure was the point you were making) would generate a compile error. So we could perhaps support Gunnar's approach after all. A meta-annotation might look cleaner, but it might become painful to define a lot of these. Matt > > >> >> On 13 Jan 2017, at 15:22, Gunnar Morling wrote: >> >> >> >> As a variation of Matt's idea, an optional index() parameter could be >> added: >> >> >> >> @Size(1) >> >> @Size(3) >> >> @ApplyConstraintTo(constraint=Size.class, index=1, >> target=WRAPPED_VALUE) >> >> List nicknames; >> >> >> >> It could be omitted (via a default value of -1 or similar) if there is >> >> only one constraint of the type in question: >> >> >> >> @NotNull >> >> @Email >> >> @ApplyConstraintTo(constraint=NotNull.class, >> target=ANNOTATED_ELEMENT) >> >> Optional email; >> >> >> >> Does the trick, though it's still a tad verbose. >> >> >> >> >> >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard : >> >>> >> >>> On 13 Jan 2017, at 13:29, Guillaume Smet >> wrote: >> >>> >> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling > > >> >>> wrote: >> >>>> >> >>>> Unfortunately, validationAppliesTo() is already taken: >> >>>> >> >>>> http://beanvalidation.org/latest-draft/spec/#constraintsdefi >> nitionimplementation-constraintdefinition-validationappliesto >> >>>> >> >>>> It's used to distinguish between return value and cross-parameter >> >>>> constraints. >> >>>> >> >>>> Any other name I can think of right now would make up for much >> >>>> confusion with that option. >> >>> >> >>> >> >>> Too good to be true :). >> >>> >> >>> That being said, I'm wondering if we could reuse it and just add 2 >> other >> >>> values to ConstraintTarget. All in all, it's the same concept. The >> default >> >>> being IMPLICIT is not too bad either. >> >>> >> >>> >> >>> Right I think it?s worth exploring. >> >>> I still like my group repurposing trick though even if it offenses >> the clean >> >>> camp :) >> >>> >> > > I still can't figure out how you would use the group trick in conjunction > with validation of a "real" group. > > Matt > > [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.5 > > >> >>> _______________________________________________ >> >>> beanvalidation-dev mailing list >> >>> beanvalidation-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> >> >> >> _______________________________________________ >> >> beanvalidation-dev mailing list >> >> beanvalidation-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> > >> > >> > _______________________________________________ >> > beanvalidation-dev mailing list >> > beanvalidation-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/9adf00b1/attachment.html From gunnar at hibernate.org Fri Jan 13 11:55:13 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 13 Jan 2017 17:55:13 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> Message-ID: Right, Emmanuel's example isn't legal: "It is a compile-time error if, in a declaration context or type context, there are multiple annotations of a repeatable annotation type T and any annotations of the containing annotation type of T." But it's also says that given a single instance of the repeatable annotation type and the container annotation is valid: @Min @Min.List({@Min}) BooYahh foo; I'm not sure how the ordering is defined - and if so, how. If we could confirm that this case can be resolved deterministically, too, then it should be doable. > A meta-annotation might look cleaner, but it might become painful to define a lot of these. What exactly do you mean here? Can you give an example? 2017-01-13 17:39 GMT+01:00 Matt Benson : > > > On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson wrote: >> >> >> On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard >> wrote: >>> >>> s/other/order from the JVM/ >>> >>> > On 13 Jan 2017, at 15:54, Emmanuel Bernard >>> > wrote: >>> > >>> > I looked at that, and I?m not sure you are guaranteed to get an other. >>> > Plus you have this problem >>> > >>> > @Min >>> > @Min.List({@Min, @Min}) >>> > @Min >>> > BooYahh foo; >>> > >> >> >> I would have thought the same; however per [1] order is guaranteed. Your >> additional concern is still there. Maybe it would be cleaner to support this >> using meta-constraint annotations. > > > Actually, per the same section of the JLS, your example is referred to as > "obtuse" (which I'm sure was the point you were making) would generate a > compile error. So we could perhaps support Gunnar's approach after all. A > meta-annotation might look cleaner, but it might become painful to define a > lot of these. > > Matt >> >> >>> >>> >> On 13 Jan 2017, at 15:22, Gunnar Morling wrote: >>> >> >>> >> As a variation of Matt's idea, an optional index() parameter could be >>> >> added: >>> >> >>> >> @Size(1) >>> >> @Size(3) >>> >> @ApplyConstraintTo(constraint=Size.class, index=1, >>> >> target=WRAPPED_VALUE) >>> >> List nicknames; >>> >> >>> >> It could be omitted (via a default value of -1 or similar) if there is >>> >> only one constraint of the type in question: >>> >> >>> >> @NotNull >>> >> @Email >>> >> @ApplyConstraintTo(constraint=NotNull.class, >>> >> target=ANNOTATED_ELEMENT) >>> >> Optional email; >>> >> >>> >> Does the trick, though it's still a tad verbose. >>> >> >>> >> >>> >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard : >>> >>> >>> >>> On 13 Jan 2017, at 13:29, Guillaume Smet >>> >>> wrote: >>> >>> >>> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling >>> >>> >>> >>> wrote: >>> >>>> >>> >>>> Unfortunately, validationAppliesTo() is already taken: >>> >>>> >>> >>>> >>> >>>> http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimplementation-constraintdefinition-validationappliesto >>> >>>> >>> >>>> It's used to distinguish between return value and cross-parameter >>> >>>> constraints. >>> >>>> >>> >>>> Any other name I can think of right now would make up for much >>> >>>> confusion with that option. >>> >>> >>> >>> >>> >>> Too good to be true :). >>> >>> >>> >>> That being said, I'm wondering if we could reuse it and just add 2 >>> >>> other >>> >>> values to ConstraintTarget. All in all, it's the same concept. The >>> >>> default >>> >>> being IMPLICIT is not too bad either. >>> >>> >>> >>> >>> >>> Right I think it?s worth exploring. >>> >>> I still like my group repurposing trick though even if it offenses >>> >>> the clean >>> >>> camp :) >>> >>> >> >> >> I still can't figure out how you would use the group trick in conjunction >> with validation of a "real" group. >> >> Matt >> >> [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.5 >> >>> >>> >>> _______________________________________________ >>> >>> beanvalidation-dev mailing list >>> >>> beanvalidation-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >>> >> >>> >> _______________________________________________ >>> >> beanvalidation-dev mailing list >>> >> beanvalidation-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >>> > >>> > >>> > _______________________________________________ >>> > beanvalidation-dev mailing list >>> > beanvalidation-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >>> >>> >>> _______________________________________________ >>> beanvalidation-dev mailing list >>> beanvalidation-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> >> > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From mbenson at apache.org Fri Jan 13 12:54:50 2017 From: mbenson at apache.org (Matt Benson) Date: Fri, 13 Jan 2017 11:54:50 -0600 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> Message-ID: On Fri, Jan 13, 2017 at 10:55 AM, Gunnar Morling wrote: > Right, Emmanuel's example isn't legal: > > "It is a compile-time error if, in a declaration context or type > context, there are multiple annotations of a repeatable annotation > type T and any annotations of the containing annotation type of T." > > But it's also says that given a single instance of the repeatable > annotation type and the container annotation is valid: > > @Min > @Min.List({@Min}) > BooYahh foo; > > I'm not sure how the ordering is defined - and if so, how. If we could > confirm that this case can be resolved deterministically, too, then it > should be doable. > Oh, right. :) Yeah, it would probably be natural to assume that the resulting Min.List would contain all Min annotations in the order in which they were encountered, but any assumption could also be dangerous. > > > A meta-annotation might look cleaner, but it might become painful to > define a lot of these. > > What exactly do you mean here? Can you give an example? > > I'm thinking of an extension to the composed constraint feature. So: @Size(min=3) @ConstraintsApplyTo(WRAPPED_VALUE) @Constraint public @interface Nickname { String message() default ""; Class groups() default {}; Class[] payload() default {}; } @Size(min=1) @Nickname List nicknames; The example is necessarily contrived where we're talking about a "normal" typed extraction container, but should be applicable to: @Size(min=1) @Nickname StringList nicknames; As I warned, however, defining these might become tedious. It might be helpful to define a mechanism (like that supported by Spring) to map annotation elements: @Size @ConstraintsApplyTo(WRAPPED_VALUE) @Constraint public @interface WrappedSize { @MapTo(type=Size.class, attribute="min") int min() default 0; @MapTo(type=Size.class, attribute="max") int max() default Integer.MAX_VALUE; String message() default ""; Class groups() default {}; Class[] payload() default {}; } @Size(1) @WrappedSize(min=3) StringList nicknames; Matt > 2017-01-13 17:39 GMT+01:00 Matt Benson : > > > > > > On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson > wrote: > >> > >> > >> On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard < > emmanuel at hibernate.org> > >> wrote: > >>> > >>> s/other/order from the JVM/ > >>> > >>> > On 13 Jan 2017, at 15:54, Emmanuel Bernard > >>> > wrote: > >>> > > >>> > I looked at that, and I?m not sure you are guaranteed to get an > other. > >>> > Plus you have this problem > >>> > > >>> > @Min > >>> > @Min.List({@Min, @Min}) > >>> > @Min > >>> > BooYahh foo; > >>> > > >> > >> > >> I would have thought the same; however per [1] order is guaranteed. Your > >> additional concern is still there. Maybe it would be cleaner to support > this > >> using meta-constraint annotations. > > > > > > Actually, per the same section of the JLS, your example is referred to as > > "obtuse" (which I'm sure was the point you were making) would generate a > > compile error. So we could perhaps support Gunnar's approach after all. A > > meta-annotation might look cleaner, but it might become painful to > define a > > lot of these. > > > > Matt > >> > >> > >>> > >>> >> On 13 Jan 2017, at 15:22, Gunnar Morling > wrote: > >>> >> > >>> >> As a variation of Matt's idea, an optional index() parameter could > be > >>> >> added: > >>> >> > >>> >> @Size(1) > >>> >> @Size(3) > >>> >> @ApplyConstraintTo(constraint=Size.class, index=1, > >>> >> target=WRAPPED_VALUE) > >>> >> List nicknames; > >>> >> > >>> >> It could be omitted (via a default value of -1 or similar) if there > is > >>> >> only one constraint of the type in question: > >>> >> > >>> >> @NotNull > >>> >> @Email > >>> >> @ApplyConstraintTo(constraint=NotNull.class, > >>> >> target=ANNOTATED_ELEMENT) > >>> >> Optional email; > >>> >> > >>> >> Does the trick, though it's still a tad verbose. > >>> >> > >>> >> > >>> >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard >: > >>> >>> > >>> >>> On 13 Jan 2017, at 13:29, Guillaume Smet > > >>> >>> wrote: > >>> >>> > >>> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling > >>> >>> > >>> >>> wrote: > >>> >>>> > >>> >>>> Unfortunately, validationAppliesTo() is already taken: > >>> >>>> > >>> >>>> > >>> >>>> http://beanvalidation.org/latest-draft/spec/# > constraintsdefinitionimplementation-constraintdefinition- > validationappliesto > >>> >>>> > >>> >>>> It's used to distinguish between return value and cross-parameter > >>> >>>> constraints. > >>> >>>> > >>> >>>> Any other name I can think of right now would make up for much > >>> >>>> confusion with that option. > >>> >>> > >>> >>> > >>> >>> Too good to be true :). > >>> >>> > >>> >>> That being said, I'm wondering if we could reuse it and just add 2 > >>> >>> other > >>> >>> values to ConstraintTarget. All in all, it's the same concept. The > >>> >>> default > >>> >>> being IMPLICIT is not too bad either. > >>> >>> > >>> >>> > >>> >>> Right I think it?s worth exploring. > >>> >>> I still like my group repurposing trick though even if it offenses > >>> >>> the clean > >>> >>> camp :) > >>> >>> > >> > >> > >> I still can't figure out how you would use the group trick in > conjunction > >> with validation of a "real" group. > >> > >> Matt > >> > >> [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html# > jls-9.7.5 > >> > >>> > >>> >>> _______________________________________________ > >>> >>> beanvalidation-dev mailing list > >>> >>> beanvalidation-dev at lists.jboss.org > >>> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > >>> >> > >>> >> _______________________________________________ > >>> >> beanvalidation-dev mailing list > >>> >> beanvalidation-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > >>> > > >>> > > >>> > _______________________________________________ > >>> > beanvalidation-dev mailing list > >>> > beanvalidation-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > >>> > >>> > >>> _______________________________________________ > >>> beanvalidation-dev mailing list > >>> beanvalidation-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > >> > >> > > > > > > _______________________________________________ > > beanvalidation-dev mailing list > > beanvalidation-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/e018785a/attachment-0001.html From gunnar at hibernate.org Mon Jan 16 06:43:37 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 16 Jan 2017 12:43:37 +0100 Subject: [bv-dev] Making ConstraintValidator#initialize() a default method Message-ID: Hi, Someone suggested, now that we require Java 8, to make ConstraintValidator#initialize() a (no-op) default method [1]. This will save implementors of constraints without any attributes from providing their own empty implementation. I think it's a compelling idea; does anyone see a reason speaking against it? Thanks, --Gunnar [1] https://hibernate.atlassian.net/projects/BVAL/issues/BVAL-555 From gunnar at hibernate.org Mon Jan 16 06:46:02 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 16 Jan 2017 12:46:02 +0100 Subject: [bv-dev] Improved java.time support follow-up In-Reply-To: References: Message-ID: Just closed this PR as there was no further feedback. Thanks all who worked on this change, glad to see it done! 2017-01-10 11:46 GMT+01:00 Guillaume Smet : > Hi, > > On Tue, Jan 10, 2017 at 9:12 AM, Gunnar Morling > wrote: >> >> Based on this feedback and the original proposal [1]. I've sent a pull >> request for updating the spec >> (https://github.com/beanvalidation/beanvalidation-spec/pull/122). Note that >> you need to take a look at the API project, too, in order to get the full >> picture (as we include API types directly from there). >> >> Any comments on this change are welcome. I'll leave the PR open until the >> end of the week end then merge it if nothing more comes up. > > > I merged this PR by mistake just now but feel free to add comment on it, > I'll ajust what needs to be adjusted. > > Thanks! > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From misterm at gmail.com Mon Jan 16 06:54:04 2017 From: misterm at gmail.com (Michael Nascimento) Date: Mon, 16 Jan 2017 09:54:04 -0200 Subject: [bv-dev] Making ConstraintValidator#initialize() a default method In-Reply-To: References: Message-ID: It's compelling, +1 Regards, Michael On Mon, Jan 16, 2017 at 9:43 AM, Gunnar Morling wrote: > Hi, > > Someone suggested, now that we require Java 8, to make > ConstraintValidator#initialize() a (no-op) default method [1]. > > This will save implementors of constraints without any attributes from > providing their own empty implementation. > > I think it's a compelling idea; does anyone see a reason speaking against > it? > > Thanks, > > --Gunnar > > [1] https://hibernate.atlassian.net/projects/BVAL/issues/BVAL-555 > _______________________________________________ > 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/20170116/ff639e0d/attachment.html From guillaume.smet at gmail.com Mon Jan 16 09:08:57 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 16 Jan 2017 15:08:57 +0100 Subject: [bv-dev] Making ConstraintValidator#initialize() a default method In-Reply-To: References: Message-ID: On Mon, Jan 16, 2017 at 12:43 PM, Gunnar Morling wrote: > Someone suggested, now that we require Java 8, to make > ConstraintValidator#initialize() a (no-op) default method [1]. > Makes sense. +1. -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170116/9984bd5d/attachment.html From gunnar at hibernate.org Mon Jan 16 10:35:21 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 16 Jan 2017 16:35:21 +0100 Subject: [bv-dev] Value extraction open issue #9: extractors for specific parameterized types Message-ID: Hi, Another one from the open issues list: Should we allow extractors to be defined for specific parameterized types, e.g.: public class ListOfIntegerExtractor implements ValueExtractor> { ... } public class ListOfStringExtractor implements ValueExtractor> { ... } Currently, a value extractor may only mark a wild-card type parameter with @ExtractedValue: public class ListOfStringExtractor implements ValueExtractor> { ... } The reason being to cut down on complexity and the lack of any use case. Is there any scenario where one would want to extract a list of Integer differently than a list String? I would thus only support wildcard type parameters in extractor definitions, unless someone else can see a compelling use case for the more liberal model. Note we always can relax the requirement in a future revision. Thanks, --Gunnar From otaviopolianasantana at gmail.com Tue Jan 17 05:25:46 2017 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Tue, 17 Jan 2017 08:25:46 -0200 Subject: [bv-dev] Making ConstraintValidator#initialize() a default method In-Reply-To: References: Message-ID: Makes sense +1 On Mon, Jan 16, 2017 at 12:08 PM, Guillaume Smet wrote: > On Mon, Jan 16, 2017 at 12:43 PM, Gunnar Morling > wrote: > >> Someone suggested, now that we require Java 8, to make >> ConstraintValidator#initialize() a (no-op) default method [1]. >> > > Makes sense. +1. > > -- > Guillaume > > _______________________________________________ > 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170117/292cf665/attachment.html From emmanuel at hibernate.org Tue Jan 17 07:56:55 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 17 Jan 2017 13:56:55 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> Message-ID: <6610CBD0-24F6-459E-BCDC-0C0A92F2930C@hibernate.org> > On 13 Jan 2017, at 18:54, Matt Benson wrote: > > As I warned, however, defining these might become tedious. It might be helpful to define a mechanism (like that supported by Spring) to map annotation elements: > > @Size > @ConstraintsApplyTo(WRAPPED_VALUE) > @Constraint > public @interface WrappedSize { > > @MapTo(type=Size.class, attribute="min") > int min() default 0; > > @MapTo(type=Size.class, attribute="max") > int max() default Integer.MAX_VALUE; > > String message() default ""; > Class groups() default {}; > Class[] payload() default {}; > } > > @Size(1) @WrappedSize(min=3) StringList nicknames; > If you mean something like @MapTo, the spec already has that via @OverridesAttribute AFAIK we invented it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170117/f97ad144/attachment-0001.html From christian at kaltepoth.de Tue Jan 17 09:05:11 2017 From: christian at kaltepoth.de (Christian Kaltepoth) Date: Tue, 17 Jan 2017 15:05:11 +0100 Subject: [bv-dev] Value extraction open issue #7: Should type argument constraints trigger cascaded validation? In-Reply-To: References: Message-ID: +1 for requiring @Valid. IMO it is more consistent to require it. 2017-01-13 17:23 GMT+01:00 Matt Benson : > > > On Fri, Jan 13, 2017 at 7:48 AM, Emmanuel Bernard > wrote: > >> > >> > I *think* Matt and Emmanuel support that @Valid should be required >> > (but confirmation would be nice). What do others think? >> >> Yes I?m in favor of requiring it. >> > > I agree. > > Matt > > >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > -- 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/20170117/d2171c3e/attachment.html From mbenson at apache.org Tue Jan 17 11:22:52 2017 From: mbenson at apache.org (Matt Benson) Date: Tue, 17 Jan 2017 10:22:52 -0600 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: <6610CBD0-24F6-459E-BCDC-0C0A92F2930C@hibernate.org> References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> <6610CBD0-24F6-459E-BCDC-0C0A92F2930C@hibernate.org> Message-ID: On Tue, Jan 17, 2017 at 6:56 AM, Emmanuel Bernard wrote: > > On 13 Jan 2017, at 18:54, Matt Benson wrote: > > As I warned, however, defining these might become tedious. It might be > helpful to define a mechanism (like that supported by Spring) to map > annotation elements: > > @Size > @ConstraintsApplyTo(WRAPPED_VALUE) > @Constraint > public @interface WrappedSize { > > @MapTo(type=Size.class, attribute="min") > int min() default 0; > > @MapTo(type=Size.class, attribute="max") > int max() default Integer.MAX_VALUE; > > String message() default ""; > Class groups() default {}; > Class[] payload() default {}; > } > > @Size(1) @WrappedSize(min=3) StringList nicknames; > > > If you mean something like @MapTo, the spec already has that via > @OverridesAttribute > AFAIK we invented it. > > Sorry, it's been awhile since I've used BV in real life. But yes, that's what I mean. Matt > _______________________________________________ > 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/20170117/5d0f9add/attachment.html From mbenson at apache.org Tue Jan 17 11:27:46 2017 From: mbenson at apache.org (Matt Benson) Date: Tue, 17 Jan 2017 10:27:46 -0600 Subject: [bv-dev] Making ConstraintValidator#initialize() a default method In-Reply-To: References: Message-ID: +1 Matt On Tue, Jan 17, 2017 at 4:25 AM, Ot?vio Gon?alves de Santana < otaviopolianasantana at gmail.com> wrote: > Makes sense +1 > > On Mon, Jan 16, 2017 at 12:08 PM, Guillaume Smet > wrote: > >> On Mon, Jan 16, 2017 at 12:43 PM, Gunnar Morling >> wrote: >> >>> Someone suggested, now that we require Java 8, to make >>> ConstraintValidator#initialize() a (no-op) default method [1]. >>> >> >> Makes sense. +1. >> >> -- >> Guillaume >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170117/ab037ca4/attachment.html From mbenson at apache.org Tue Jan 17 11:30:51 2017 From: mbenson at apache.org (Matt Benson) Date: Tue, 17 Jan 2017 10:30:51 -0600 Subject: [bv-dev] Value extraction open issue #9: extractors for specific parameterized types In-Reply-To: References: Message-ID: I am okay with starting out with wildcards only, *unless* anyone can make a convincing argument that this will make it more difficult to support specific type mappings later on. Matt On Mon, Jan 16, 2017 at 9:35 AM, Gunnar Morling wrote: > Hi, > > Another one from the open issues list: Should we allow extractors to > be defined for specific parameterized types, e.g.: > > public class ListOfIntegerExtractor implements > ValueExtractor> { ... } > > public class ListOfStringExtractor implements > ValueExtractor> { ... } > > Currently, a value extractor may only mark a wild-card type parameter > with @ExtractedValue: > > public class ListOfStringExtractor implements > ValueExtractor> { ... } > > The reason being to cut down on complexity and the lack of any use > case. Is there any scenario where one would want to extract a list of > Integer differently than a list String? > > I would thus only support wildcard type parameters in extractor > definitions, unless someone else can see a compelling use case for the > more liberal model. Note we always can relax the requirement in a > future revision. > > 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/20170117/d4af48cc/attachment.html From gunnar at hibernate.org Tue Jan 17 11:54:33 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 17 Jan 2017 17:54:33 +0100 Subject: [bv-dev] Making ConstraintValidator#initialize() a default method In-Reply-To: References: Message-ID: Seems there is general love for it :) I've created PRs https://github.com/beanvalidation/beanvalidation-api/pull/78 and https://github.com/beanvalidation/beanvalidation-spec/pull/127 for API and spec, respectively. --gunnar 2017-01-17 17:27 GMT+01:00 Matt Benson : > +1 > > Matt > > On Tue, Jan 17, 2017 at 4:25 AM, Ot?vio Gon?alves de Santana > wrote: >> >> Makes sense +1 >> >> On Mon, Jan 16, 2017 at 12:08 PM, Guillaume Smet >> wrote: >>> >>> On Mon, Jan 16, 2017 at 12:43 PM, Gunnar Morling >>> wrote: >>>> >>>> Someone suggested, now that we require Java 8, to make >>>> ConstraintValidator#initialize() a (no-op) default method [1]. >>> >>> >>> Makes sense. +1. >>> >>> -- >>> Guillaume >>> >>> _______________________________________________ >>> 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 emmanuel at hibernate.org Tue Jan 17 13:39:10 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 17 Jan 2017 19:39:10 +0100 Subject: [bv-dev] Value extraction open issue #9: extractors for specific parameterized types In-Reply-To: References: Message-ID: <713AA280-E065-46DE-88C6-871909E852AC@hibernate.org> Like you I think a better support is workable later. Though it looks unnecessary. > On 17 Jan 2017, at 17:30, Matt Benson wrote: > > I am okay with starting out with wildcards only, *unless* anyone can make a convincing argument that this will make it more difficult to support specific type mappings later on. > > Matt > >> On Mon, Jan 16, 2017 at 9:35 AM, Gunnar Morling wrote: >> Hi, >> >> Another one from the open issues list: Should we allow extractors to >> be defined for specific parameterized types, e.g.: >> >> public class ListOfIntegerExtractor implements >> ValueExtractor> { ... } >> >> public class ListOfStringExtractor implements >> ValueExtractor> { ... } >> >> Currently, a value extractor may only mark a wild-card type parameter >> with @ExtractedValue: >> >> public class ListOfStringExtractor implements >> ValueExtractor> { ... } >> >> The reason being to cut down on complexity and the lack of any use >> case. Is there any scenario where one would want to extract a list of >> Integer differently than a list String? >> >> I would thus only support wildcard type parameters in extractor >> definitions, unless someone else can see a compelling use case for the >> more liberal model. Note we always can relax the requirement in a >> future revision. >> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170117/0a21aa38/attachment.html From gunnar at hibernate.org Wed Jan 18 09:19:15 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 18 Jan 2017 15:19:15 +0100 Subject: [bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo? In-Reply-To: References: <3E2A40FC-50F1-49E2-9B28-8C9E4788E7DA@hibernate.org> <74DA3EB7-3D4C-4409-8A2B-455543D119CE@hibernate.org> <6610CBD0-24F6-459E-BCDC-0C0A92F2930C@hibernate.org> Message-ID: So I got confirmation from the JDK team that there is no guaranteed order for retrieved annotations in the general case, causing any index-based approach to fail. The problem I see about the meta-annotation approach is that it doesn't allow to re-use existing constraints without additional changes, i.e. there's a migration hurdle for 3rd-party constraints (similar to having a dedicated validationWrappedValue() member). Now Emmanuel made the proposal to use the payload() feature for this: @Size(1) Size(min=3, payload=Unwrapping.Unwrap.class) StringList nicknames; While it feels a bit hack-ish, it puts the setting to the right level (individual constraints as opposed to entire elements). So I think it's a good basis, so we could move on with this for the time being and hopefully get some exposure + feedback in an Alpha release. --Gunnar 2017-01-17 17:22 GMT+01:00 Matt Benson : > > > On Tue, Jan 17, 2017 at 6:56 AM, Emmanuel Bernard > wrote: >> >> >> On 13 Jan 2017, at 18:54, Matt Benson wrote: >> >> As I warned, however, defining these might become tedious. It might be >> helpful to define a mechanism (like that supported by Spring) to map >> annotation elements: >> >> @Size >> @ConstraintsApplyTo(WRAPPED_VALUE) >> @Constraint >> public @interface WrappedSize { >> >> @MapTo(type=Size.class, attribute="min") >> int min() default 0; >> >> @MapTo(type=Size.class, attribute="max") >> int max() default Integer.MAX_VALUE; >> >> String message() default ""; >> Class groups() default {}; >> Class[] payload() default {}; >> } >> >> @Size(1) @WrappedSize(min=3) StringList nicknames; >> >> >> If you mean something like @MapTo, the spec already has that via >> @OverridesAttribute >> AFAIK we invented it. >> > > Sorry, it's been awhile since I've used BV in real life. But yes, that's > what I mean. > > Matt >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From hendrik.ebbers at me.com Fri Jan 20 02:55:18 2017 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Fri, 20 Jan 2017 08:55:18 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: The final version :) I have some money at my JUG and will create some stickers ;) What should be added as a text? http://beanvalidation.org ? Java Bean Validation 2 ? > Am 03.01.2017 um 18:44 schrieb Gunnar Morling : > > Yes, it is awesome, absolutely love it. Kudos to your friend and you for making this happen! > > Am 03.01.2017 6:28 nachm. schrieb "Hendrik Ebbers" >: > THX, but I haven't done the sketch ;) A designer made it. If you all like it I will order a vector based logo. > > Von meinem iPhone gesendet > > Am 03.01.2017 um 18:00 schrieb Christian Kaltepoth >: > >> Hendrik, >> >> I love your sketch of the logo. It looks great! Thanks for working on it! >> >> Christian >> >> >> >> 2017-01-02 23:13 GMT+01:00 Hendrik Ebbers >: >> Hi all & a happy new year! >> >> I received a first sketch for the JSR logo (final version will be vector based). What do you think? >> >> Cheers, >> >> Hendrik >> >> >> >> >>> Am 31.12.2016 um 17:35 schrieb Christian Kaltepoth >: >>> >>> 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 >: >>> 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 >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > 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/20170120/9d753194/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: duke_lupe.png Type: image/png Size: 39034 bytes Desc: not available Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/9d753194/attachment-0001.png From guillaume.smet at gmail.com Fri Jan 20 03:01:10 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 20 Jan 2017 09:01:10 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: Hi Hendrik, On Fri, Jan 20, 2017 at 8:55 AM, Hendrik Ebbers wrote: > The final version :) > Nice. Is there a SVG version available so that we can redimension it easily? It would also be nice to have a clear license. -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/2d76755a/attachment.html From hendrik.ebbers at me.com Fri Jan 20 03:04:17 2017 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Fri, 20 Jan 2017 09:04:17 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: Hi, I will get the SVG version by mail. About the Licence: The JUG Dortmund has payed for it. So currently it?s owned by the JUG Dortmund. Since the JUG is no real organization I think it?s owned by me. What should I do to define a license for it? Any suggestions? > Am 20.01.2017 um 09:01 schrieb Guillaume Smet : > > Hi Hendrik, > > On Fri, Jan 20, 2017 at 8:55 AM, Hendrik Ebbers > wrote: > The final version :) > > Nice. Is there a SVG version available so that we can redimension it easily? > > It would also be nice to have a clear license. > > -- > Guillaume > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/5171d3f8/attachment.html From hendrik.ebbers at me.com Fri Jan 20 03:12:34 2017 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Fri, 20 Jan 2017 09:12:34 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: <8DFE975D-C237-42D9-90A7-883EE029C214@me.com> ?. and the SVG file > Am 20.01.2017 um 09:04 schrieb Hendrik Ebbers : > > Hi, > > I will get the SVG version by mail. > > About the Licence: The JUG Dortmund has payed for it. So currently it?s owned by the JUG Dortmund. Since the JUG is no real organization I think it?s owned by me. What should I do to define a license for it? Any suggestions? > >> Am 20.01.2017 um 09:01 schrieb Guillaume Smet >: >> >> Hi Hendrik, >> >> On Fri, Jan 20, 2017 at 8:55 AM, Hendrik Ebbers > wrote: >> The final version :) >> >> Nice. Is there a SVG version available so that we can redimension it easily? >> >> It would also be nice to have a clear license. >> >> -- >> Guillaume >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/7ce700ff/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: duke_lupe-01.svg Type: image/svg+xml Size: 20403 bytes Desc: not available Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/7ce700ff/attachment-0001.bin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/7ce700ff/attachment-0003.html From gunnar at hibernate.org Fri Jan 20 03:42:33 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 20 Jan 2017 09:42:33 +0100 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: <8DFE975D-C237-42D9-90A7-883EE029C214@me.com> References: <8DFE975D-C237-42D9-90A7-883EE029C214@me.com> Message-ID: Hendrik, A massive thank you again to you for making this happen! I really like the logo a lot. I'll get back to you on the licensing question off-list. --Gunnar 2017-01-20 9:12 GMT+01:00 Hendrik Ebbers : > ?. and the SVG file > > > > Am 20.01.2017 um 09:04 schrieb Hendrik Ebbers : > > Hi, > > I will get the SVG version by mail. > > About the Licence: The JUG Dortmund has payed for it. So currently it?s > owned by the JUG Dortmund. Since the JUG is no real organization I think > it?s owned by me. What should I do to define a license for it? Any > suggestions? > > Am 20.01.2017 um 09:01 schrieb Guillaume Smet : > > Hi Hendrik, > > On Fri, Jan 20, 2017 at 8:55 AM, Hendrik Ebbers > wrote: >> >> The final version :) > > > Nice. Is there a SVG version available so that we can redimension it easily? > > It would also be nice to have a clear license. > > -- > Guillaume > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From otaviojava at java.net Fri Jan 20 06:46:57 2017 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Fri, 20 Jan 2017 09:46:57 -0200 Subject: [bv-dev] Happy Holidays and State of the Union In-Reply-To: References: Message-ID: That's really nice :) On Fri, Jan 20, 2017 at 5:55 AM, Hendrik Ebbers wrote: > The final version :) > > I have some money at my JUG and will create some stickers ;) What should > be added as a text? http://beanvalidation.org ? Java Bean Validation 2 ? > > Am 03.01.2017 um 18:44 schrieb Gunnar Morling < > gunnar.morling at googlemail.com>: > > Yes, it is awesome, absolutely love it. Kudos to your friend and you for > making this happen! > > Am 03.01.2017 6:28 nachm. schrieb "Hendrik Ebbers" >: > >> THX, but I haven't done the sketch ;) A designer made it. If you all like >> it I will order a vector based logo. >> >> Von meinem iPhone gesendet >> >> Am 03.01.2017 um 18:00 schrieb Christian Kaltepoth < >> christian at kaltepoth.de>: >> >> Hendrik, >> >> I love your sketch of the logo. It looks great! Thanks for working on it! >> >> Christian >> >> >> >> 2017-01-02 23:13 GMT+01:00 Hendrik Ebbers : >> >>> Hi all & a happy new year! >>> >>> I received a first sketch for the JSR logo (final version will be vector >>> based). What do you think? >>> >>> Cheers, >>> >>> Hendrik >>> >>> >>> >>> >>> Am 31.12.2016 um 17:35 schrieb Christian Kaltepoth < >>> christian at kaltepoth.de>: >>> >>> 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 : >>> >>>> 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-Dec >>>> ember/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 >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/dfd70d94/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: duke_lupe.png Type: image/png Size: 39034 bytes Desc: not available Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/dfd70d94/attachment-0001.png From gunnar at hibernate.org Fri Jan 20 12:04:23 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 20 Jan 2017 18:04:23 +0100 Subject: [bv-dev] Progress report and Early Draft 1 Message-ID: Hi all, I've put together a blog post on the progress we made so far [1]. Can you please help to spread the word and share/(re-)tweet the link [2]? The more people we reach, the better. I've also updated the open questions around container value extraction as per our recent discussions [3]. I'll start some more threads on some of the remaining questions. Looking at what we have, I think we're ready to post an Early Draft 1 to the JCP and I'm planning to do so within the next few days. As always, any feedback is welcome. --Gunnar [1] http://beanvalidation.org/news/2017/01/19/bean-validation-2-0-progress-report/ [2] https://twitter.com/gunnarmorling/status/822437573813538817 [3] http://beanvalidation.org/latest-draft/spec/#_open_questions From otaviojava at java.net Fri Jan 20 12:20:47 2017 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Fri, 20 Jan 2017 15:20:47 -0200 Subject: [bv-dev] Progress report and Early Draft 1 In-Reply-To: References: Message-ID: Nice report! I have shared with a lot of communities and also the adopt a JSR project. On Fri, Jan 20, 2017 at 3:04 PM, Gunnar Morling wrote: > Hi all, > > I've put together a blog post on the progress we made so far [1]. Can > you please help to spread the word and share/(re-)tweet the link [2]? > The more people we reach, the better. > > I've also updated the open questions around container value extraction > as per our recent discussions [3]. I'll start some more threads on > some of the remaining questions. > > Looking at what we have, I think we're ready to post an Early Draft 1 > to the JCP and I'm planning to do so within the next few days. > > As always, any feedback is welcome. > > --Gunnar > > [1] http://beanvalidation.org/news/2017/01/19/bean- > validation-2-0-progress-report/ > [2] https://twitter.com/gunnarmorling/status/822437573813538817 > [3] http://beanvalidation.org/latest-draft/spec/#_open_questions > _______________________________________________ > 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170120/0f83a043/attachment.html