<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>A couple of remarks, I am not tied to @ValidateOnCall. We can find better names and/or a different split. I like @IsInvariant described by Sebastian which means @ValidateOnCall(INCLUDE_GETTERS) in my proposal. My concern is that it would not scale for bean/package level settings nor allow to disable validation on a particular method.</div><div><br></div><div>My point being, if we finally agree on the proper default and overriding approach we can refine names. </div><div><br></div><div>Gerhard, let me try and clarify your position. You like 1.b but you want to be able to change the default global behavior per archive (with a validation.xml setting) if needed and therefore that's why you voted for 2.b. I don't see a big problem with that. My two concerns are:</div><div><br></div><div>- I am not sure that would be useful very often in practice but I imagine it could be useful in a pure service archive</div><div>- to know the behavior, it forces people to look for a validation.xml to see what behavior is set but as long as we have the default defined in 1, that's not a huge concern to me. </div><div><br></div><div>Emmanuel<br><br>On 11 déc. 2012, at 23:12, Gerhard Petracek <<a href="mailto:gerhard.petracek@gmail.com">gerhard.petracek@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div><div>hi sebastian,</div><div><br></div><div>i was going to +1 1.b as well, but i don't agree with point #1 (if it is globally and/or users have to do it in any case) and #2.</div><div>(with @ValidateOnCall i'm ok with both default behaviours, if there is a way to change it for a bv-archive.)</div>
<div><br></div><div>regards,</div><div>gerhard</div></div></div><div><br></div><br><br><div class="gmail_quote">2012/12/11 Sebastian Thomschke <span dir="ltr"><<a href="mailto:sebastian.thomschke@web.de" target="_blank">sebastian.thomschke@web.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm +1 for option 1b.<br>
<br>
A constraint annotation added to a regular non-getter method always<br>
describes a return value contract whereas a constraint annotation added<br>
to a getter method may be meant to be<br>
a) a return value contract or<br>
b) a property constraint, that only is supposed to be considered during<br>
bean validation.<br>
<br>
For getter method constraint annotation my gut feeling is, that you<br>
usually want b) - a property constraint definition.<br>
<br>
In OVal we have the annotation @IsInvariant to mark the constraints<br>
defined on a getter for being return value contracts if not present the<br>
constraints are not interpreted as return value contracts.<br>
<br>
Regards,<br>
<br>
Seb<br>
<div class="HOEnZb"><div class="h5"><br>
On 11.12.2012 16:50, Emmanuel Bernard wrote:<br>
> That should hopefully be the last round. Here are the alternatives that<br>
> I think are viable <a href="http://goo.gl/ubjn3" target="_blank">http://goo.gl/ubjn3</a><br>
><br>
> Please give your feedback.<br>
><br>
> Emmanuel<br>
><br>
> On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:<br>
>> For method validation, we have so far managed to get away with<br>
>> requiring an annotation based metadata to direct how method validation<br>
>> behaves.<br>
>><br>
>> One question that popped up during the recent write up is whether or not<br>
>> getters should be considered regular methods and thus be intercepted and<br>
>> validation by CDI or AspectJ interceptors.<br>
>><br>
>> I have my own ideas, but I'd like to get your opinion on the subject.<br>
>><br>
>> Emmanuel<br>
>> _______________________________________________<br>
>> beanvalidation-dev mailing list<br>
>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>beanvalidation-dev mailing list</span><br><span><a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a></span><br></div></blockquote></body></html>