+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(a)lists.jboss.org>
Send beanvalidation-dev mailing list submissions to
beanvalidation-dev(a)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(a)lists.jboss.org
You can reach the person managing the list at
beanvalidation-dev-owner(a)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(a)gmail.com>
Subject: Re: [bv-dev] Should getters be considered methods during
validation
To: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
Message-ID:
<CAGJtJfEbm4FpFB2V7iH50dABrH=
RsbAsdWHOUeXRYP_j8OzPew(a)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(a)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(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)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/...
------------------------------
Message: 2
Date: Tue, 11 Dec 2012 21:17:56 +0100
From: Sebastian Thomschke <sebastian.thomschke(a)web.de>
Subject: Re: [bv-dev] Should getters be considered methods during
validation
To: beanvalidation-dev(a)lists.jboss.org
Message-ID: <50C794F4.4010508(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)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(a)gmail.com>
Subject: Re: [bv-dev] Should getters be considered methods during
validation
To: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
Message-ID:
<
CAGJtJfHQBtYg-ObT1MCBF47O_RdasnCtyDYv_X-JkbJe3bt_Ug(a)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(a)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(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)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/...
------------------------------
Message: 4
Date: Wed, 12 Dec 2012 00:46:40 +0100
From: Hardy Ferentschik <hardy(a)hibernate.org>
Subject: Re: [bv-dev] BVAL-192 'exclusive' flag for
@DecimalMin/@DecimalMax
To: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
Message-ID: <E2199861-9455-4CFA-90F1-05C2CCCF4D92(a)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(a)hibernate.org>
Subject: Re: [bv-dev] Should getters be considered methods during
validation
To: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
Cc: beanvalidation-dev List <beanvalidation-dev(a)lists.jboss.org>
Message-ID: <A828568E-799B-4BEF-A704-01CCCCDD2E89(a)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(a)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(a)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(a)lists.jboss.org
>> >>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev(a)lists.jboss.org
>> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)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/...
------------------------------
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
End of beanvalidation-dev Digest, Vol 17, Issue 11
**************************************************