From guillaume.smet at gmail.com  Sun Apr  1 06:56:49 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Sun, 1 Apr 2018 12:56:49 +0200
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec
	and TCK
In-Reply-To: <CADGJaX9-=fMD8GeW7-OUsj9nvHruuPzn6iXvG577+41cS6CJ-A@mail.gmail.com>
References: <CAE9L6G3Vvqk7GszazTLbdz_gOe9JewUDUf0N9wPcfVYKO3KLyw@mail.gmail.com>
	<CALt0+o-jpzZfg3m0R4gdpaCiTyb6mKVPrc1d2OVQG4HNvGNPPw@mail.gmail.com>
	<CAE9L6G0cGkRac=-xuAp2ubjpFjZzkG3jN5g1DpAEE3FpkyJV6A@mail.gmail.com>
	<CALt0+o-Gcz32H1FcKfHJQ4XVZg9E47b0BgjPtsa9r-rHXtMVcQ@mail.gmail.com>
	<CADGJaX95SY0pkhtahicge5zTabq=f8ZDrjpnMTCdhNMYejz0Qg@mail.gmail.com>
	<CALt0+o_UPGOnFKYDL=ovhNOsgjTr5RJqDseqam4DWymEdD-6+Q@mail.gmail.com>
	<CADGJaX9-=fMD8GeW7-OUsj9nvHruuPzn6iXvG577+41cS6CJ-A@mail.gmail.com>
Message-ID: <CALt0+o8YfJe9yAoSmAbtV+g4y83xVDqSKTAiqRD2NKB49ZGJJw@mail.gmail.com>

On Sat, Mar 31, 2018 at 2:19 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

>
>>    - If more than one are marked with @UnwrapByDefault, a
>>       ConstraintDeclarationException is raised.
>>
>> I don't think we can or should do this, instead no extractor should be
> applied in this case. It'd contradict quite clearly the spec's wording
> "Otherwise, no value extractor is applied." Also the idea was that
> implicitly applied extractors should be applied implicitly if it's doable
> unambiguously, but they shouldn't cause any sort of configuration exception
> otherwise.
>

Yes, I'm stating that the spec is incorrect here and should be corrected.

In all the other cases when we have competing value extractors, we throw an
error. Why not in this case?

Typically, you would have your constraints applied on the container
elements, then you add another value extractor, and your constraints are
then applied silently to the container instead of the container elements.
That sounds like the wrong approach.

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180401/adee536a/attachment.html 

From mbenson at apache.org  Tue Apr  3 17:22:25 2018
From: mbenson at apache.org (Matt Benson)
Date: Tue, 3 Apr 2018 16:22:25 -0500
Subject: [bv-dev] Clarification regarding executable parameter/return value
 validation with group sequence redefinition
Message-ID: <CAE9L6G1TF1DYa3rhEmHSP-WjCr-THGUmLTpS2EAMF2BOoR05ag@mail.gmail.com>

Hello, I am encountering failures on three tests from
MethodValidationTest in the TCK:

* #constructorParameterValidationWithRedefinedDefaultGroupSequence()
* #methodParameterValidationWithRedefinedDefaultGroupSequence()
* #methodReturnValueValidationWithRedefinedDefaultGroupSequence()

In each case I am failing to pick up a @Size constraint from the
Default group of an Item parameter or Order return value. However, due
to the group sequence redefinition of Basic, Default on the bean class
in question I am confused as to why I am expected to pick up the
failures from the Default group after having encountered a @NotNull
constraint violation in the Basic group. Thanks for any help here.

Matt

From guillaume.smet at gmail.com  Wed Apr  4 09:23:32 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 4 Apr 2018 15:23:32 +0200
Subject: [bv-dev] Clarification regarding executable parameter/return
 value validation with group sequence redefinition
In-Reply-To: <CAE9L6G1TF1DYa3rhEmHSP-WjCr-THGUmLTpS2EAMF2BOoR05ag@mail.gmail.com>
References: <CAE9L6G1TF1DYa3rhEmHSP-WjCr-THGUmLTpS2EAMF2BOoR05ag@mail.gmail.com>
Message-ID: <CALt0+o99rOyNHOte_KpdqMysUCwmvxFfuzVhY47c8Za50nm4WA@mail.gmail.com>

Hi Matt,

On Tue, Apr 3, 2018 at 11:22 PM, Matt Benson <mbenson at apache.org> wrote:

> Hello, I am encountering failures on three tests from
> MethodValidationTest in the TCK:
>
> * #constructorParameterValidationWithRedefinedDefaultGroupSequence()
> * #methodParameterValidationWithRedefinedDefaultGroupSequence()
> * #methodReturnValueValidationWithRedefinedDefaultGroupSequence()
>
> In each case I am failing to pick up a @Size constraint from the
> Default group of an Item parameter or Order return value. However, due
> to the group sequence redefinition of Basic, Default on the bean class
> in question I am confused as to why I am expected to pick up the
> failures from the Default group after having encountered a @NotNull
> constraint violation in the Basic group. Thanks for any help here.
>

I would tend to agree with you. (The fact that Item also has a different
Basic group does not help to understand the issue though).

AFAIU the spec (
http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationprocess-validationroutine-methodconstructorvalidation),
we should do:
- For each group
  - For each parameter, apply constraints
  - For each cascading parameter, cascade

This in no particular order if there is no group sequence. If a group
sequence is defined, we should exit as soon as we have a violation for a
given group

Currently, the RI does:
- For each group
  - For each parameter, apply constraints
    - exit as soon as I have a constraint if group sequence
- For each group
  - For each cascading parameter, cascade
    - exit as soon as I have a constraint if group sequence

In the aforementioned case:
1/ we apply the Basic constraints for the parameter constraints
2/ we exit as soon as we have a violation, we don't validate the Default
group
3/ we apply cascading
   - no violation for the Basic group
   - we validate the default group
   - we exit as soon as we have a violation

As per spec, I think we should exit just after 2/

Gunnar, any insights?

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180404/2ba5e62a/attachment-0001.html 

From gunnar at hibernate.org  Fri Apr  6 09:13:07 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 6 Apr 2018 15:13:07 +0200
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec
	and TCK
In-Reply-To: <CALt0+o8YfJe9yAoSmAbtV+g4y83xVDqSKTAiqRD2NKB49ZGJJw@mail.gmail.com>
References: <CAE9L6G3Vvqk7GszazTLbdz_gOe9JewUDUf0N9wPcfVYKO3KLyw@mail.gmail.com>
	<CALt0+o-jpzZfg3m0R4gdpaCiTyb6mKVPrc1d2OVQG4HNvGNPPw@mail.gmail.com>
	<CAE9L6G0cGkRac=-xuAp2ubjpFjZzkG3jN5g1DpAEE3FpkyJV6A@mail.gmail.com>
	<CALt0+o-Gcz32H1FcKfHJQ4XVZg9E47b0BgjPtsa9r-rHXtMVcQ@mail.gmail.com>
	<CADGJaX95SY0pkhtahicge5zTabq=f8ZDrjpnMTCdhNMYejz0Qg@mail.gmail.com>
	<CALt0+o_UPGOnFKYDL=ovhNOsgjTr5RJqDseqam4DWymEdD-6+Q@mail.gmail.com>
	<CADGJaX9-=fMD8GeW7-OUsj9nvHruuPzn6iXvG577+41cS6CJ-A@mail.gmail.com>
	<CALt0+o8YfJe9yAoSmAbtV+g4y83xVDqSKTAiqRD2NKB49ZGJJw@mail.gmail.com>
Message-ID: <CADGJaX-MCjROcZzWbXcDZDA3bHZQZqg0qwO004eC7B_vxGNCTQ@mail.gmail.com>

2018-04-01 12:56 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> On Sat, Mar 31, 2018 at 2:19 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>>
>>>    - If more than one are marked with @UnwrapByDefault, a
>>>       ConstraintDeclarationException is raised.
>>>
>>> I don't think we can or should do this, instead no extractor should be
>> applied in this case. It'd contradict quite clearly the spec's wording
>> "Otherwise, no value extractor is applied." Also the idea was that
>> implicitly applied extractors should be applied implicitly if it's doable
>> unambiguously, but they shouldn't cause any sort of configuration exception
>> otherwise.
>>
>
> Yes, I'm stating that the spec is incorrect here and should be corrected.
>

We quite clearly say that an exception is raised, so we cannot really
change that in the spec.

In all the other cases when we have competing value extractors, we throw an
> error. Why not in this case?
>

The thinking was that *implicit* unwrapping should only be done if
unambiguously possible. I.e. this implicit process shouldn't cause a
configuration exception if it cannot be performed.

Typically, you would have your constraints applied on the container
> elements, then you add another value extractor, and your constraints are
> then applied silently to the container instead of the container elements.
> That sounds like the wrong approach.
>

I think that's just the nature of implicit application of extractors. You
also could say "you've applied constraints to the container, then you add a
value extractor, and your constraints are then applied silently to the
container elements". We went this route to make it comfortable (no Unwrap
payload needed) to apply constraints to non-generic wrappers such as
OptionalInt.


> --
> Guillaume
>
>
> _______________________________________________
> 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/20180406/34e2b171/attachment.html 

From gunnar at hibernate.org  Fri Apr  6 12:06:59 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 6 Apr 2018 18:06:59 +0200
Subject: [bv-dev] Clarification regarding executable parameter/return
 value validation with group sequence redefinition
In-Reply-To: <CALt0+o99rOyNHOte_KpdqMysUCwmvxFfuzVhY47c8Za50nm4WA@mail.gmail.com>
References: <CAE9L6G1TF1DYa3rhEmHSP-WjCr-THGUmLTpS2EAMF2BOoR05ag@mail.gmail.com>
	<CALt0+o99rOyNHOte_KpdqMysUCwmvxFfuzVhY47c8Za50nm4WA@mail.gmail.com>
Message-ID: <CADGJaX-A-Aq7BZWtiGe0aBdJATR9UUyBB=E2BumSJ8w1M+ocTw@mail.gmail.com>

Hi,

I believe that the test is correct, since the redefinition of default group
sequences is local to the type hosting @GroupSequence, i.e. it's not
propagated to associated elements (referenced properties, method parameters
or return values). Please check out
http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationprocess-validationroutine-graphvalidation
and examples 5.29 - 5.32 which show a comparable situation (only for
regular bean validation, not for method validation).

For OrderServiceWithRedefinedDefaultGroupSequence this means, that
@GroupSequence({ Basic.class,
OrderServiceWithRedefinedDefaultGroupSequence.class }) only applies to the
constraints hosted on the methods of that class itself, but not to the
constraints on the Item class as we traverse to it. As the default group is
requested, validation of the constraints on
OrderServiceWithRedefinedDefaultGroupSequence will stop after the Basic
group, but for Item, all constraints of its default group (which isn't
re-defined) are validated. Hence the @Size constraint is expected within
the set of constraint violations.

--Gunnar


2018-04-04 15:23 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> Hi Matt,
>
> On Tue, Apr 3, 2018 at 11:22 PM, Matt Benson <mbenson at apache.org> wrote:
>
>> Hello, I am encountering failures on three tests from
>> MethodValidationTest in the TCK:
>>
>> * #constructorParameterValidationWithRedefinedDefaultGroupSequence()
>> * #methodParameterValidationWithRedefinedDefaultGroupSequence()
>> * #methodReturnValueValidationWithRedefinedDefaultGroupSequence()
>>
>> In each case I am failing to pick up a @Size constraint from the
>> Default group of an Item parameter or Order return value. However, due
>> to the group sequence redefinition of Basic, Default on the bean class
>> in question I am confused as to why I am expected to pick up the
>> failures from the Default group after having encountered a @NotNull
>> constraint violation in the Basic group. Thanks for any help here.
>>
>
> I would tend to agree with you. (The fact that Item also has a different
> Basic group does not help to understand the issue though).
>
> AFAIU the spec (http://beanvalidation.org/2.0/spec/#
> constraintdeclarationvalidationprocess-validationroutine-
> methodconstructorvalidation), we should do:
> - For each group
>   - For each parameter, apply constraints
>   - For each cascading parameter, cascade
>
> This in no particular order if there is no group sequence. If a group
> sequence is defined, we should exit as soon as we have a violation for a
> given group
>
> Currently, the RI does:
> - For each group
>   - For each parameter, apply constraints
>     - exit as soon as I have a constraint if group sequence
> - For each group
>   - For each cascading parameter, cascade
>     - exit as soon as I have a constraint if group sequence
>
> In the aforementioned case:
> 1/ we apply the Basic constraints for the parameter constraints
> 2/ we exit as soon as we have a violation, we don't validate the Default
> group
> 3/ we apply cascading
>    - no violation for the Basic group
>    - we validate the default group
>    - we exit as soon as we have a violation
>
> As per spec, I think we should exit just after 2/
>
> Gunnar, any insights?
>
> --
> Guillaume
>
> _______________________________________________
> 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/20180406/1071d219/attachment.html 

From mbenson at apache.org  Mon Apr  9 18:46:25 2018
From: mbenson at apache.org (Matt Benson)
Date: Mon, 9 Apr 2018 17:46:25 -0500
Subject: [bv-dev] Question on Formal Group Definitions rules
Message-ID: <CAE9L6G3a9jR6TR5Ntcn4gknSdg=L1YNSxLNPsaOJPZLDhT3oLQ@mail.gmail.com>

Hi all,
With reference to spec v2.0 section 5.4.6, I am having trouble with item
3b, where a class X has no @GroupSequence annotation, among its Default
constraints are:

if X has a direct superclass Y, every constraint in the group Default
of Y *this
rule is necessary in case Y redefines the group Default*

Consider this with the concrete example in
GroupSequenceIsolationTest#testCorrectDefaultSequenceInheritance3(). Here
B3 extends A, whose @GroupSequence is defined as { Minimal, A }. Rule 4
says of a class X with a @GroupSequence annotation:

If X does have a @GroupSequence annotation, the group Default contains
every constraint belonging to every group declared by the @GroupSequence
annotation.

I thus conclude that Default contains for A: { Minimal, A } and that
Default for B3 should contain { B3 (per rule 3a), Minimal, A } and that the
validation performed at line 128 should detect violations at:

nickname (group B3)
size (group Minimal)
name (group A)

The assertions of the test, however, expect only the first two. Why is A
omitted? If the sequence defined by a superclass to be respected, where is
this specified? TBH I would think it would make sense, but my read of this
section specifically set me down a path of removing this behavior from the
Apache BVal codebase as I couldn't find a justification for it.

Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180409/71eee744/attachment-0001.html 

From guillaume.smet at gmail.com  Wed Apr 11 11:18:37 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 11 Apr 2018 17:18:37 +0200
Subject: [bv-dev] Question on Formal Group Definitions rules
In-Reply-To: <CAE9L6G3a9jR6TR5Ntcn4gknSdg=L1YNSxLNPsaOJPZLDhT3oLQ@mail.gmail.com>
References: <CAE9L6G3a9jR6TR5Ntcn4gknSdg=L1YNSxLNPsaOJPZLDhT3oLQ@mail.gmail.com>
Message-ID: <CALt0+o-bwhOQLeV_jSAX88xDYEVFMV7-O-i-TShKE6S63pFCbg@mail.gmail.com>

Hi Matt,

On Tue, Apr 10, 2018 at 12:46 AM, Matt Benson <mbenson at apache.org> wrote:
> The assertions of the test, however, expect only the first two. Why is A
omitted? If the sequence defined by a superclass to be respected, where is
this specified? TBH I would think it would make sense, but my read of this
section specifically set me down a path of removing this behavior from the
Apache BVal codebase as I couldn't find a justification for it.

Isn't it because it's a group sequence? So as long as a constraint of the
Minimal group fails, the ones from the group A are not checked.

As you can see in the following assertions, when size is valid, name is
checked.

AFAICS, it's the behavior I would expect but maybe I'm missing something?

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180411/de9311a4/attachment.html 

From mbenson at apache.org  Wed Apr 11 12:34:26 2018
From: mbenson at apache.org (Matt Benson)
Date: Wed, 11 Apr 2018 16:34:26 +0000
Subject: [bv-dev] Question on Formal Group Definitions rules
In-Reply-To: <CALt0+o-bwhOQLeV_jSAX88xDYEVFMV7-O-i-TShKE6S63pFCbg@mail.gmail.com>
References: <CAE9L6G3a9jR6TR5Ntcn4gknSdg=L1YNSxLNPsaOJPZLDhT3oLQ@mail.gmail.com>
	<CALt0+o-bwhOQLeV_jSAX88xDYEVFMV7-O-i-TShKE6S63pFCbg@mail.gmail.com>
Message-ID: <CAE9L6G2rVx4oWP7pkzRvz+MJZyfNj1tmSpR9iv=P0dNvKm2=TA@mail.gmail.com>

Again, I think the problem is that I simply can't see what in the spec
dictates that, and in what order, an overridden Default sequence from a
superclass should be inherited for sequential validation by the child. The
rules simply say for class X with no group sequence, that its default
constraints include all those of the Default group of superclass Y. Where
is it dictated that Y's sequence be respected?

Thanks,
Matt

On Wed, Apr 11, 2018, 10:19 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi Matt,
>
> On Tue, Apr 10, 2018 at 12:46 AM, Matt Benson <mbenson at apache.org> wrote:
> > The assertions of the test, however, expect only the first two. Why is A
> omitted? If the sequence defined by a superclass to be respected, where is
> this specified? TBH I would think it would make sense, but my read of this
> section specifically set me down a path of removing this behavior from the
> Apache BVal codebase as I couldn't find a justification for it.
>
> Isn't it because it's a group sequence? So as long as a constraint of the
> Minimal group fails, the ones from the group A are not checked.
>
> As you can see in the following assertions, when size is valid, name is
> checked.
>
> AFAICS, it's the behavior I would expect but maybe I'm missing something?
>
> --
> Guillaume
> _______________________________________________
> 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/20180411/81e87a28/attachment.html 

From guillaume.smet at gmail.com  Thu Apr 12 05:59:02 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 12 Apr 2018 11:59:02 +0200
Subject: [bv-dev] Question on Formal Group Definitions rules
In-Reply-To: <CAE9L6G2rVx4oWP7pkzRvz+MJZyfNj1tmSpR9iv=P0dNvKm2=TA@mail.gmail.com>
References: <CAE9L6G3a9jR6TR5Ntcn4gknSdg=L1YNSxLNPsaOJPZLDhT3oLQ@mail.gmail.com>
	<CALt0+o-bwhOQLeV_jSAX88xDYEVFMV7-O-i-TShKE6S63pFCbg@mail.gmail.com>
	<CAE9L6G2rVx4oWP7pkzRvz+MJZyfNj1tmSpR9iv=P0dNvKm2=TA@mail.gmail.com>
Message-ID: <CALt0+o-+5e1J6EDZKDDTejB3uwPYNgnijxKE0Ki7eoERvp+J5A@mail.gmail.com>

On Wed, Apr 11, 2018 at 6:34 PM, Matt Benson <mbenson at apache.org> wrote:

> Again, I think the problem is that I simply can't see what in the spec
> dictates that, and in what order, an overridden Default sequence from a
> superclass should be inherited for sequential validation by the child. The
> rules simply say for class X with no group sequence, that its default
> constraints include all those of the Default group of superclass Y. Where
> is it dictated that Y's sequence be respected?
>

I agree something is not very clear in the spec regarding this behavior.

We would have to clarify with Gunnar what was the intent of the spec.

He's off for ~ a month so this will have to wait. I opened
https://hibernate.atlassian.net/browse/BVAL-711.

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180412/09426650/attachment.html 

From mbenson at apache.org  Fri Apr 13 15:12:15 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 13 Apr 2018 14:12:15 -0500
Subject: [bv-dev] group conversion conflict between bean properties
 constrained in different ways
Message-ID: <CAE9L6G2gF1nWardQUyH+ZJzJN0wSshhzYvycPtyr_nH3UWtgaA@mail.gmail.com>

Hi all,

Consider
InvalidGroupConversionInPropertyLevelOverridingTest#testGroupConversionsAreAdditiveAndExceptionIsThrownForMultipleConversionWithSameSource():

This test purports to enforce that a ValidationException is thrown because
a property specifies  multiple group conversions from the Default group.
However, the example actually specifies one via the annotated getter, and
the other via the XML-configured field. I can't find that the spec is
perfectly clear on this, but it is clear that a property should be accessed
using the mechanism of constraint declaration. I don't recall where, but
the TCK tests proper validation of field vs. getter even when the objects
returned are different. I would therefore argue that there could be some
legitimate reason to apply a different group conversion to field vs.
getter, and that the test case should be changed to specify the XML
constraint via getter as does the User class definition overridden.

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180413/b8027863/attachment.html 

From guillaume.smet at gmail.com  Tue Apr 17 06:32:11 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 17 Apr 2018 12:32:11 +0200
Subject: [bv-dev] group conversion conflict between bean properties
 constrained in different ways
In-Reply-To: <CAE9L6G2gF1nWardQUyH+ZJzJN0wSshhzYvycPtyr_nH3UWtgaA@mail.gmail.com>
References: <CAE9L6G2gF1nWardQUyH+ZJzJN0wSshhzYvycPtyr_nH3UWtgaA@mail.gmail.com>
Message-ID: <CALt0+o-3MwbUDAaV4NJp6mhkscjV0Oo3xRd8++eEHXWnHaZPWw@mail.gmail.com>

Agreed: https://hibernate.atlassian.net/browse/BVTCK-205 .

Feedback welcome on the PR.

Thanks.

On Fri, Apr 13, 2018 at 9:12 PM, Matt Benson <mbenson at apache.org> wrote:

> Hi all,
>
> Consider InvalidGroupConversionInPropertyLevelOverridingTest#
> testGroupConversionsAreAdditiveAndExceptionIsThrownForMultip
> leConversionWithSameSource():
>
> This test purports to enforce that a ValidationException is thrown because
> a property specifies  multiple group conversions from the Default group.
> However, the example actually specifies one via the annotated getter, and
> the other via the XML-configured field. I can't find that the spec is
> perfectly clear on this, but it is clear that a property should be accessed
> using the mechanism of constraint declaration. I don't recall where, but
> the TCK tests proper validation of field vs. getter even when the objects
> returned are different. I would therefore argue that there could be some
> legitimate reason to apply a different group conversion to field vs.
> getter, and that the test case should be changed to specify the XML
> constraint via getter as does the User class definition overridden.
>
> Matt
>
> _______________________________________________
> 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/20180417/42370479/attachment.html