[bv-dev] Should getters be considered methods during validation

Emmanuel Bernard emmanuel at hibernate.org
Wed Dec 12 03:26:15 EST 2012


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.

My point being, if we finally agree on the proper default and overriding approach we can refine names. 

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:

- I am not sure that would be useful very often in practice but I imagine it could be useful in a pure service archive
- 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. 

Emmanuel

On 11 déc. 2012, at 23:12, Gerhard Petracek <gerhard.petracek at gmail.com> wrote:

> hi sebastian,
> 
> 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.
> (with @ValidateOnCall i'm ok with both default behaviours, if there is a way to change it for a bv-archive.)
> 
> regards,
> gerhard
> 
> 
> 
> 2012/12/11 Sebastian Thomschke <sebastian.thomschke at web.de>
>> Hi,
>> 
>> I'm +1 for option 1b.
>> 
>> A constraint annotation added to a regular non-getter method always
>> describes a return value contract whereas a constraint annotation added
>> to a getter method may be meant to be
>> a) a return value contract or
>> b) a property constraint, that only is supposed to be considered during
>> bean validation.
>> 
>> For getter method constraint annotation my gut feeling is, that you
>> usually want b) - a property constraint definition.
>> 
>> In OVal we have the annotation @IsInvariant to mark the constraints
>> defined on a getter for being return value contracts if not present the
>> constraints are not interpreted as return value contracts.
>> 
>> Regards,
>> 
>> Seb
>> 
>> On 11.12.2012 16:50, Emmanuel Bernard wrote:
>> > That should hopefully be the last round. Here are the alternatives that
>> > I think are viable http://goo.gl/ubjn3
>> >
>> > Please give your feedback.
>> >
>> > Emmanuel
>> >
>> > On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
>> >> For method validation, we have so far managed to get away with
>> >> requiring an annotation based metadata to direct how method validation
>> >> behaves.
>> >>
>> >> One question that popped up during the recent write up is whether or not
>> >> getters should be considered regular methods and thus be intercepted and
>> >> validation by CDI or AspectJ interceptors.
>> >>
>> >> I have my own ideas, but I'd like to get your opinion on the subject.
>> >>
>> >> Emmanuel
>> >> _______________________________________________
>> >> 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/20121212/f3554c91/attachment-0001.html 


More information about the beanvalidation-dev mailing list