[bv-dev] beanvalidation-dev Digest, Vol 17, Issue 11

Wed Dec 12 05:28:02 EST 2012

+1 for *1.b*


*Faissal *
---
Préservons l'environnement. N'imprimez ce courriel que si nécessaire.
Please consider the environment before printing this e-mail.


2012/12/12 <beanvalidation-dev-request at lists.jboss.org>

> Send beanvalidation-dev mailing list submissions to
>         beanvalidation-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> or, via email, send a message with subject or body 'help' to
>         beanvalidation-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         beanvalidation-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of beanvalidation-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Should getters be considered methods during validation
>       (Gerhard Petracek)
>    2. Re: Should getters be considered methods during validation
>       (Sebastian Thomschke)
>    3. Re: Should getters be considered methods during validation
>       (Gerhard Petracek)
>    4. Re: BVAL-192 'exclusive' flag for @DecimalMin/@DecimalMax
>       (Hardy Ferentschik)
>    5. Re: Should getters be considered methods during validation
>       (Emmanuel Bernard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 11 Dec 2012 19:32:40 +0100
> From: Gerhard Petracek <gerhard.petracek at gmail.com>
> Subject: Re: [bv-dev] Should getters be considered methods during
>         validation
> To: beanvalidation-dev List <beanvalidation-dev at lists.jboss.org>
> Message-ID:
>         <CAGJtJfEbm4FpFB2V7iH50dABrH=
> RsbAsdWHOUeXRYP_j8OzPew at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> +1 for 2.b but -1 for a package annotation and/or config.
>
> regards,
> gerhard
>
>
>
> 2012/12/11 Emmanuel Bernard <emmanuel at hibernate.org>
>
> > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121211/bce4236b/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 11 Dec 2012 21:17:56 +0100
> From: Sebastian Thomschke <sebastian.thomschke at web.de>
> Subject: Re: [bv-dev] Should getters be considered methods during
>         validation
> To: beanvalidation-dev at lists.jboss.org
> Message-ID: <50C794F4.4010508 at web.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 11 Dec 2012 23:12:49 +0100
> From: Gerhard Petracek <gerhard.petracek at gmail.com>
> Subject: Re: [bv-dev] Should getters be considered methods during
>         validation
> To: beanvalidation-dev List <beanvalidation-dev at lists.jboss.org>
> Message-ID:
>         <
> CAGJtJfHQBtYg-ObT1MCBF47O_RdasnCtyDYv_X-JkbJe3bt_Ug at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121211/7b412da7/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Wed, 12 Dec 2012 00:46:40 +0100
> From: Hardy Ferentschik <hardy at hibernate.org>
> Subject: Re: [bv-dev] BVAL-192 'exclusive' flag for
>         @DecimalMin/@DecimalMax
> To: beanvalidation-dev  List <beanvalidation-dev at lists.jboss.org>
> Message-ID: <E2199861-9455-4CFA-90F1-05C2CCCF4D92 at hibernate.org>
> Content-Type: text/plain; charset=us-ascii
>
>
> >>> @DecimalMax(value = "0.0", exclusive = true)
> >>
> >> Can we name it "inclusive" rather than "exclusive"? Personally I prefer
> >> positive variable/method names as I think they read better, in
> particular
> >> when it comes to negation.
> >
> > I think inclusive also has a clearer meaning, it took me three reads
> > through to work out what the purpose was. I wondered if Hardy picked
> > exclusive for a sensible default value, but gave up trying to get my
> > head around it (newborn baby is my excuse).
>
> Well, I just used 'exclude', because it was used in the jira ticket. Now
> that I think about it 'inclusive' is much better.
> Maybe I can play the newborn card as well?  Does it still count after 4
> months? I definitely still feel tired.
>
> Welcome to the club.
>
> --Hardy
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 12 Dec 2012 09:26:15 +0100
> From: Emmanuel Bernard <emmanuel at hibernate.org>
> Subject: Re: [bv-dev] Should getters be considered methods during
>         validation
> To: beanvalidation-dev List <beanvalidation-dev at lists.jboss.org>
> Cc: beanvalidation-dev List <beanvalidation-dev at lists.jboss.org>
> Message-ID: <A828568E-799B-4BEF-A704-01CCCCDD2E89 at hibernate.org>
> Content-Type: text/plain; charset="utf-8"
>
> 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.html
>
> ------------------------------
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> End of beanvalidation-dev Digest, Vol 17, Issue 11
> **************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121212/ae957fd2/attachment-0001.html