<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">2016-09-26 14:00 GMT+02:00 Michael Nascimento <span dir="ltr"><<a href="mailto:misterm@gmail.com" target="_blank">misterm@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Sep 26, 2016 at 5:18 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>> wrote:<br>
> Great proposal! I like your scheme for capturing all types to be supported<br>
> and how you describe the validation routine.<br>
<br>
</span>Nice!<br>
<span><br>
> * Why is it that you use compareTo() over isAfter()/isBefore()? I reckon the<br>
> latter are not as widely supported amongst JSR 310 types?<br>
<br>
</span>Unfortunately, it's not in any interface though. So we have to stick<br>
to what the interfaces provide... :-)<br></blockquote><div><br></div><div>Yes, we could say something about these methods explicitly, but using the Comparable contract definitely simplifies things.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> * What are the shortcomings meant by "2.1.1. Working around limitations in<br>
> ConstraintValidator that prevent the above strategy"?<br>
<br>
</span>All those sections without content are still to be written. In this<br>
case, according to the spec, there is no way to write a<br>
PastTemporalAccessorComparable<wbr>ConstraintValidator extends<br>
ConstraintValidator<Past, ? extends TemporalAccessor & Comparable<?>><br>
or something like it, which is the natural choice. Making it just<br>
"extends ConstraintValidator<TemporalAc<wbr>cessor>" won't make it fail at<br>
the right phase if @Past is applied to a non-Comparable<br>
TemporalAccessor. I have a few ideas on how to address that, but maybe<br>
now you can get thinking too :-)<br></blockquote><div><br></div><div>Ok, got you.</div><div><br></div><div>That'd only be a problem though if you wanted to write a single validator implementation for all of them, right? I'm wondering whether one wouldn't use several more specific implementations anyways, given one needs to invoke a specific static now() method?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> * What do you have in mind with regards to "2.4. "Simple" TemporalAmount<br>
> implementations support"?<br>
<br>
</span>These are TemporalAmount(s) with a single unit. For these, @Max and<br>
@Min support should work for the single unit they support.<br></blockquote><div><br></div><div>Ah, seeing now that Duration and Period implement these. I don't think I like @Max/@Min for these as it's not clear what the unit of the expected value is. New constraints may be more useful here:</div><div><br></div><div> public void save(@MaxDuration(value=60, unit=ChronoUnit.SECONDS) Duration d) { ... }</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> * We need a way to expose the ClockProvider to ConstraintValidator<br>
> implementations (injection via CDI may be used, but BV must be usable<br>
> without CDI, too). Adding a new method<br>
> ConstraintValidatorContext#get<wbr>ClockProvider() seems the most obvious choice<br>
> (currently the RI provides<br>
> HibernateConstraintValidatorCo<wbr>ntext#getTimeProvider() for that purpose).<br>
<br>
</span>Sure, did I remove that? :-)<br></blockquote><div><br></div><div>No, I think it was not yet part of the proposal :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> * Regarding Duration/Period, how about handling this separately? It seems we<br>
> could add this in a second step, allowing to align quickly on the<br>
> @Future/@Past additions and add support for it to the RI.<br>
<br>
</span>Your call :-) I was just trying to consolidate everything about<br>
JSR-310 in a single proposal; there's nothing wrong with splitting it.<br></blockquote><div><br></div><div>Ok, I'd say if think you can come up with something for this quickly, go for it. Otherwise let's keep it separately. It'd be nice to have a first cut of stuff we can take and provide support for in the RI.</div><div><br></div><div>Thanks a lot for your effort, Michael, that's much appreciated!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards,<br>
Michael<br>
<div><div>______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss<wbr>.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div></div>