Hi Michael,

Great proposal! I like your scheme for capturing all types to be supported and how you describe the validation routine.

Some questions/thoughts:

* Why is it that you use compareTo() over isAfter()/isBefore()? I reckon the latter are not as widely supported amongst JSR 310 types?
* What are the shortcomings meant by "2.1.1. Working around limitations in ConstraintValidator that prevent the above strategy"?
* What do you have in mind with regards to "2.4. "Simple" TemporalAmount implementations support"?
* We need a way to expose the ClockProvider to ConstraintValidator implementations (injection via CDI may be used, but BV must be usable without CDI, too). Adding a new method ConstraintValidatorContext#getClockProvider() seems the most obvious choice (currently the RI provides HibernateConstraintValidatorContext#getTimeProvider() for that purpose).
* Regarding Duration/Period, how about handling this separately? It seems we could add this in a second step, allowing to align quickly on the @Future/@Past additions and add support for it to the RI.

--Gunnar






2016-09-24 10:31 GMT+02:00 Gunnar Morling <gunnar@hibernate.org>:
Awesome, many thanks Michael! Going to look into the proposal asap.

--Gunnar


2016-09-23 22:08 GMT+02:00 Michael Nascimento <misterm@gmail.com>:
Hi guys,

I was finally able to write something before taking my flight this
morning. Let me know what you think:

https://github.com/sjmisterm/beanvalidation.org/blob/760cd54cb1f00bac1ae88d749d01cf80fe79f899/proposals/BVAL-496.adoc

Regards,
Michael

On Fri, Sep 23, 2016 at 4:04 AM, John Hendrikx <hjohn@xs4all.nl> wrote:
>
>>     > Another thing: If @Future and @Past support types like LocalDate,
>>     YearMonth and Year, should we perhaps enhance them to allow the user
>>     to specify that the "current" year/month/date should also be valid?
>>
>>     That's a very good point, too! This one has been specifically
>>     brought up with https://hibernate.atlassian.net/browse/BVAL-466
>>     <https://hibernate.atlassian.net/browse/BVAL-466>. It seems sensible
>>     to add an annotation parameter for this given the support for these
>>     non-instant types. When looking at your example, I'd have a hard
>>     time though to reason the exact semantics of inclusive(). I hope we
>>     could find something more descriptive?
>>
>>
>> I agree that "inclusive" isn't a good name. I'm open for any ideas. ;-)
>
> Perhaps just provide annotations for their inverse.
>
> NotFuture/NotInFuture = past + now (past inclusive)
> NotPast/NotInPast = future + now (future inclusive)
>
> Or perhaps a general modifying annotation, that can be applied to
> everything to invert the matching logic:
>
> @Not
>
> Inverts the matching logic on this element.
>
> @Not @Past
> @Not @Pattern("TRUE|FALSE")  // hard to write without the @Not
>
> --John
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev