> * Should there be a common superinterface for > Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define > the same methods? I've been wondering the same, but come to think that it doesn't give you much. You (as a user) are going to work with specific node types (as narrowed down via getKind() + as()), so I would not expect you to deal with that super-type in your code. It'd put the declaration of those methods into one place, which is nice, though I kinda like the simplicity of the current Node hierarchy, with one specific sub-type per kind. What do others think?

* Should Positive/Negative#strict() default true be provided as > #orZero() default false, for commonality with > [Past|Future]#orPresent() ? Hum, yes, good point. I think I'd prefer that. @Emmanuel, I vaguely remember we discussed this. Did you see a good reason for the current default? @All, what do you think?

Hi, 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson(a)apache.org&gt;: > After reviewing the proposed API, I have the following > questions/suggestions. I apologize if any of these have already been > considered: > > * Should there be a common superinterface for > Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define > the same methods? I've been wondering the same, but come to think that it doesn't give you much. You (as a user) are going to work with specific node types (as narrowed down via getKind() + as()), so I would not expect you to deal with that super-type in your code. It'd put the declaration of those methods into one place, which is nice, though I kinda like the simplicity of the current Node hierarchy, with one specific sub-type per kind. What do others think?

> > * Should ValidatorContext include a self type, as does Configuration? > This would facilitate the use of custom ValidatorContext subclasses. Ah, there's even an issue for this: https://hibernate.atlassian.net/browse/BVAL-211. It would have been great to make this a self-referential type from the get-go, but at this point I'd rather leave it as is. Essentially it only causes a small effort to providers which need to redeclare all the ValidatorContext methods to return their own specialised sub-type. The reason I'm reluctant to add it is that users - when upgrading existing code to BV 2.0 - will get a raw type warning when assigning ValidatorContext to a variable. I'd prefer to avoid this, at the cost of the few method re-definitions to be done by providers once, which seems acceptable. > > * Should Positive/Negative#strict() default true be provided as > #orZero() default false, for commonality with > [Past|Future]#orPresent() ? Hum, yes, good point. I think I'd prefer that. @Emmanuel, I vaguely remember we discussed this. Did you see a good reason for the current default?

@All, what do you think? > > Matt --Gunnar > _______________________________________________ > 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

On 9 May 2017, at 11:09, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: Hi all, So my preference is to make strict() default to true (so it's consistent with the default value for orPresent() of @Past/@Future). I've filed PR https://github.com/beanvalidation/beanvalidation-api/pull/106. If there are no objections by Thursday, I'll merge it then. Thanks for any comments, --Gunnar 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> On Wed 17-04-26 10:40, Gunnar Morling wrote: >> Hi, >> >> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson(a)apache.org&gt;: >>> After reviewing the proposed API, I have the following >>> questions/suggestions. I apologize if any of these have already been >>> considered: >>> >>> * Should there be a common superinterface for >>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define >>> the same methods? >> >> I've been wondering the same, but come to think that it doesn't give you much. >> >> You (as a user) are going to work with specific node types (as >> narrowed down via getKind() + as()), so I would not expect you to deal >> with that super-type in your code. It'd put the declaration of those >> methods into one place, which is nice, though I kinda like the >> simplicity of the current Node hierarchy, with one specific sub-type >> per kind. >> >> What do others think? > > I think that was my idea for not adding a hierarchy back in 1.x. > >> >>> >>> * Should ValidatorContext include a self type, as does Configuration? >>> This would facilitate the use of custom ValidatorContext subclasses. >> >> Ah, there's even an issue for this: >> https://hibernate.atlassian.net/browse/BVAL-211. >> >> It would have been great to make this a self-referential type from the >> get-go, but at this point I'd rather leave it as is. Essentially it >> only causes a small effort to providers which need to redeclare all >> the ValidatorContext methods to return their own specialised sub-type. >> >> The reason I'm reluctant to add it is that users - when upgrading >> existing code to BV 2.0 - will get a raw type warning when assigning >> ValidatorContext to a variable. I'd prefer to avoid this, at the cost >> of the few method re-definitions to be done by providers once, which >> seems acceptable. >> >>> >>> * Should Positive/Negative#strict() default true be provided as >>> #orZero() default false, for commonality with >>> [Past|Future]#orPresent() ? >> >> Hum, yes, good point. I think I'd prefer that. >> >> @Emmanuel, I vaguely remember we discussed this. Did you see a good >> reason for the current default? > > I don't even vaguely remember talking about it. Sounds good. > Actually I remember now, we discussed whether Positive#orZero should be > defaulted to true. > > I imagine that >=0 is the most common use case for @Positive (despite > the math definition). > As for @Negative, I'm on the fence. > >> >> @All, what do you think? >> >>> >>> Matt >> >> --Gunnar >> >>> _______________________________________________ >>> 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

Is inclusive more common really? My feeling is that one would want to exclude 0 more often than not. But I don't have any good idea of how to quantify that... 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > Well I object :) > You are addressing the less common scenario with this default. > >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> >> Hi all, >> >> So my preference is to make strict() default to true (so it's >> consistent with the default value for orPresent() of @Past/@Future). >> I've filed PR https://github.com/beanvalidation/beanvalidation- api/pull/106. >> >> If there are no objections by Thursday, I'll merge it then. >> >> Thanks for any comments, >> >> --Gunnar >> >> >> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote: >>>> Hi, >>>> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson(a)apache.org&gt;: >>>>> After reviewing the proposed API, I have the following >>>>> questions/suggestions. I apologize if any of these have already been >>>>> considered: >>>>> >>>>> * Should there be a common superinterface for >>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define >>>>> the same methods? >>>> >>>> I've been wondering the same, but come to think that it doesn't give you much. >>>> >>>> You (as a user) are going to work with specific node types (as >>>> narrowed down via getKind() + as()), so I would not expect you to deal >>>> with that super-type in your code. It'd put the declaration of those >>>> methods into one place, which is nice, though I kinda like the >>>> simplicity of the current Node hierarchy, with one specific sub-type >>>> per kind. >>>> >>>> What do others think? >>> >>> I think that was my idea for not adding a hierarchy back in 1.x. >>> >>>> >>>>> >>>>> * Should ValidatorContext include a self type, as does Configuration? >>>>> This would facilitate the use of custom ValidatorContext subclasses. >>>> >>>> Ah, there's even an issue for this: >>>> https://hibernate.atlassian.net/browse/BVAL-211. >>>> >>>> It would have been great to make this a self-referential type from the >>>> get-go, but at this point I'd rather leave it as is. Essentially it >>>> only causes a small effort to providers which need to redeclare all >>>> the ValidatorContext methods to return their own specialised sub-type. >>>> >>>> The reason I'm reluctant to add it is that users - when upgrading >>>> existing code to BV 2.0 - will get a raw type warning when assigning >>>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost >>>> of the few method re-definitions to be done by providers once, which >>>> seems acceptable. >>>> >>>>> >>>>> * Should Positive/Negative#strict() default true be provided as >>>>> #orZero() default false, for commonality with >>>>> [Past|Future]#orPresent() ? >>>> >>>> Hum, yes, good point. I think I'd prefer that. >>>> >>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good >>>> reason for the current default? >>> >>> I don't even vaguely remember talking about it. Sounds good. >>> Actually I remember now, we discussed whether Positive#orZero should be >>> defaulted to true. >>> >>> I imagine that >=0 is the most common use case for @Positive (despite >>> the math definition). >>> As for @Negative, I'm on the fence. >>> >>>> >>>> @All, what do you think? >>>> >>>>> >>>>> Matt >>>> >>>> --Gunnar >>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > 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

My last response might have made sense if I'd have sent my previous one (to Emmanuel) from the right address: "Less common" is an opinion. Are there survey data to back it up? By contrast, a literal or "strict" interpretation of past or future is something that cannot be questioned. ;) Matt On Tue, May 9, 2017 at 6:52 PM, Matt Benson <mbenson(a)apache.org&gt; wrote: > That's why I advocate being literal; then you don't have to guess at > people's intention. Can't they compose a version that defaults strict to > false? > > Matt > > On May 9, 2017 6:22 PM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; wrote: >> >> Is inclusive more common really? My feeling is that one would want to >> exclude 0 more often than not. But I don't have any good idea of how >> to quantify that... >> >> 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> > Well I object :) >> > You are addressing the less common scenario with this default. >> > >> >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> >> >> >> Hi all, >> >> >> >> So my preference is to make strict() default to true (so it's >> >> consistent with the default value for orPresent() of @Past/@Future). >> >> I've filed PR >> >> https://github.com/beanvalidation/beanvalidation-api/pull/106. >> >> >> >> If there are no objections by Thursday, I'll merge it then. >> >> >> >> Thanks for any comments, >> >> >> >> --Gunnar >> >> >> >> >> >> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org >: >> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote: >> >>>> Hi, >> >>>> >> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson(a)apache.org&gt;: >> >>>>> After reviewing the proposed API, I have the following >> >>>>> questions/suggestions. I apologize if any of these have already been >> >>>>> considered: >> >>>>> >> >>>>> * Should there be a common superinterface for >> >>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which >> >>>>> define >> >>>>> the same methods? >> >>>> >> >>>> I've been wondering the same, but come to think that it doesn't give >> >>>> you much. >> >>>> >> >>>> You (as a user) are going to work with specific node types (as >> >>>> narrowed down via getKind() + as()), so I would not expect you to >> >>>> deal >> >>>> with that super-type in your code. It'd put the declaration of those >> >>>> methods into one place, which is nice, though I kinda like the >> >>>> simplicity of the current Node hierarchy, with one specific sub-type >> >>>> per kind. >> >>>> >> >>>> What do others think? >> >>> >> >>> I think that was my idea for not adding a hierarchy back in 1.x. >> >>> >> >>>> >> >>>>> >> >>>>> * Should ValidatorContext include a self type, as does >> >>>>> Configuration? >> >>>>> This would facilitate the use of custom ValidatorContext subclasses. >> >>>> >> >>>> Ah, there's even an issue for this: >> >>>> https://hibernate.atlassian.net/browse/BVAL-211. >> >>>> >> >>>> It would have been great to make this a self-referential type from >> >>>> the >> >>>> get-go, but at this point I'd rather leave it as is. Essentially it >> >>>> only causes a small effort to providers which need to redeclare all >> >>>> the ValidatorContext methods to return their own specialised >> >>>> sub-type. >> >>>> >> >>>> The reason I'm reluctant to add it is that users - when upgrading >> >>>> existing code to BV 2.0 - will get a raw type warning when assigning >> >>>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost >> >>>> of the few method re-definitions to be done by providers once, which >> >>>> seems acceptable. >> >>>> >> >>>>> >> >>>>> * Should Positive/Negative#strict() default true be provided as >> >>>>> #orZero() default false, for commonality with >> >>>>> [Past|Future]#orPresent() ? >> >>>> >> >>>> Hum, yes, good point. I think I'd prefer that. >> >>>> >> >>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good >> >>>> reason for the current default? >> >>> >> >>> I don't even vaguely remember talking about it. Sounds good. >> >>> Actually I remember now, we discussed whether Positive#orZero should >> >>> be >> >>> defaulted to true. >> >>> >> >>> I imagine that >=0 is the most common use case for @Positive (despite >> >>> the math definition). >> >>> As for @Negative, I'm on the fence. >> >>> >> >>>> >> >>>> @All, what do you think? >> >>>> >> >>>>> >> >>>>> Matt >> >>>> >> >>>> --Gunnar >> >>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> > >> > >> > _______________________________________________ >> > 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

Ok I yield. But you have to admit that making sure a signed int is always 0 or positive is probably the most common though low value usage you will find. And it's low value unless you factor security consideration at which stage it become a very very good idea to litter your code with these. @Positive int age, nbrOfApples, nbrOfFriends, starRatingAverage, votingParticipants; On 10 May 2017, at 09:55, Marco Molteni <moltenma(a)gmail.com&gt; wrote: I'd go with default strict to true. It's supported by the mathematical definition of Positive/Negative number. Very difficult to know the more common scenario (in a quick informal poll between developers near me everybody was confused). I found this implementation of Zalando for a monetary amount and they use the strict interpretation for @Positive/Negative annotations and they added @PositiveOrZero/@NegativeOrZero to include the 0 : https://github.com/zalando/money-validation#usage The Eclipse Collections (ex-Goldman Sachs collections) defines positive number > 0 (strict case), https://github.com/goldmansachs/gs-collections. I would say that the more common scenario is to exclude the 0. Marco On Wed, May 10, 2017 at 3:40 AM, Matt Benson <mbenson(a)apache.org&gt; wrote: > > My last response might have made sense if I'd have sent my previous > one (to Emmanuel) from the right address: > > "Less common" is an opinion. Are there survey data to back it up? By > contrast, a literal or "strict" interpretation of past or future is > something that cannot be questioned. > > ;) > > Matt > > On Tue, May 9, 2017 at 6:52 PM, Matt Benson <mbenson(a)apache.org&gt; wrote: > > That's why I advocate being literal; then you don't have to guess at > > people's intention. Can't they compose a version that defaults strict to > > false? > > > > Matt > > > > On May 9, 2017 6:22 PM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; wrote: > >> > >> Is inclusive more common really? My feeling is that one would want to > >> exclude 0 more often than not. But I don't have any good idea of how > >> to quantify that... > >> > >> 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > >> > Well I object :) > >> > You are addressing the less common scenario with this default. > >> > > >> >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar(a)hibernate.org&gt; > >> >> wrote: > >> >> > >> >> Hi all, > >> >> > >> >> So my preference is to make strict() default to true (so it's > >> >> consistent with the default value for orPresent() of @Past/@Future). > >> >> I've filed PR > >> >> https://github.com/beanvalidation/beanvalidation-api/pull/106. > >> >> > >> >> If there are no objections by Thursday, I'll merge it then. > >> >> > >> >> Thanks for any comments, > >> >> > >> >> --Gunnar > >> >> > >> >> > >> >> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard > >> >> <emmanuel(a)hibernate.org&gt;: > >> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote: > >> >>>> Hi, > >> >>>> > >> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson(a)apache.org&gt;: > >> >>>>> After reviewing the proposed API, I have the following > >> >>>>> questions/suggestions. I apologize if any of these have already > >> >>>>> been > >> >>>>> considered: > >> >>>>> > >> >>>>> * Should there be a common superinterface for > >> >>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which > >> >>>>> define > >> >>>>> the same methods? > >> >>>> > >> >>>> I've been wondering the same, but come to think that it doesn't > >> >>>> give > >> >>>> you much. > >> >>>> > >> >>>> You (as a user) are going to work with specific node types (as > >> >>>> narrowed down via getKind() + as()), so I would not expect you to > >> >>>> deal > >> >>>> with that super-type in your code. It'd put the declaration of > >> >>>> those > >> >>>> methods into one place, which is nice, though I kinda like the > >> >>>> simplicity of the current Node hierarchy, with one specific > >> >>>> sub-type > >> >>>> per kind. > >> >>>> > >> >>>> What do others think? > >> >>> > >> >>> I think that was my idea for not adding a hierarchy back in 1.x. > >> >>> > >> >>>> > >> >>>>> > >> >>>>> * Should ValidatorContext include a self type, as does > >> >>>>> Configuration? > >> >>>>> This would facilitate the use of custom ValidatorContext > >> >>>>> subclasses. > >> >>>> > >> >>>> Ah, there's even an issue for this: > >> >>>> https://hibernate.atlassian.net/browse/BVAL-211. > >> >>>> > >> >>>> It would have been great to make this a self-referential type from > >> >>>> the > >> >>>> get-go, but at this point I'd rather leave it as is. Essentially > >> >>>> it > >> >>>> only causes a small effort to providers which need to redeclare > >> >>>> all > >> >>>> the ValidatorContext methods to return their own specialised > >> >>>> sub-type. > >> >>>> > >> >>>> The reason I'm reluctant to add it is that users - when upgrading > >> >>>> existing code to BV 2.0 - will get a raw type warning when > >> >>>> assigning > >> >>>> ValidatorContext to a variable. I'd prefer to avoid this, at the > >> >>>> cost > >> >>>> of the few method re-definitions to be done by providers once, > >> >>>> which > >> >>>> seems acceptable. > >> >>>> > >> >>>>> > >> >>>>> * Should Positive/Negative#strict() default true be provided as > >> >>>>> #orZero() default false, for commonality with > >> >>>>> [Past|Future]#orPresent() ? > >> >>>> > >> >>>> Hum, yes, good point. I think I'd prefer that. > >> >>>> > >> >>>> @Emmanuel, I vaguely remember we discussed this. Did you see a > >> >>>> good > >> >>>> reason for the current default? > >> >>> > >> >>> I don't even vaguely remember talking about it. Sounds good. > >> >>> Actually I remember now, we discussed whether Positive#orZero > >> >>> should > >> >>> be > >> >>> defaulted to true. > >> >>> > >> >>> I imagine that >=0 is the most common use case for @Positive > >> >>> (despite > >> >>> the math definition). > >> >>> As for @Negative, I'm on the fence. > >> >>> > >> >>>> > >> >>>> @All, what do you think? > >> >>>> > >> >>>>> > >> >>>>> Matt > >> >>>> > >> >>>> --Gunnar > >> >>>> > >> >>>>> _______________________________________________ > >> >>>>> 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 > >> > > >> > > >> > _______________________________________________ > >> > 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev