From mbenson at apache.org  Fri Mar  2 18:17:08 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 2 Mar 2018 17:17:08 -0600
Subject: [bv-dev] Value extractors and the TCK
In-Reply-To: <CAE9L6G0E4YAWqVuJkqWZN15UphwfN-gNd87UT_7Fz52o_N8VZA@mail.gmail.com>
References: <CAE9L6G1znR=qiNd9Kxgo31bm1Aqf07bP=q7t+ACvAFvx+YU+iw@mail.gmail.com>
	<CAE9L6G01v+u+MkzoMOk0QqbieOs85mnterbZtkSaW5=Xv2F58g@mail.gmail.com>
	<CAE9L6G21sNj+iy9bSOsOLBvbpuk9tjdhC=BaCyYhA7yaJTb33g@mail.gmail.com>
	<CAE9L6G3TH55Kw7B25bbsK=zkjFxDELUoFkt4HwYkSHPMCbc6hg@mail.gmail.com>
	<CAE9L6G3y44isEXYJDu7C1cfosMWyX1KCK0X6F1_Aebw+WpVmZg@mail.gmail.com>
	<CAE9L6G1saxg=Q2MAp4KhHWTkauJgCmPi5sNZuDvd-E9NF+jx7g@mail.gmail.com>
	<CAE9L6G2tP38DHXJN+KPPzc9UDreno6AOq9fzo2tZj3N_tSmu=Q@mail.gmail.com>
	<CAE9L6G0X0pCq1rdPnQ78orGdVu6pgJWK4qdV4xyTcwNpG6ouJA@mail.gmail.com>
	<CAE9L6G37f+xEvDJVg3foamxBxWG4KnUEUcG-_RL7qGOB3W32Qg@mail.gmail.com>
	<CAE9L6G14pcRkVVH2bgZ-_T5t8i1ha2-OaKjhcdcQa528E+hF=Q@mail.gmail.com>
	<CAE9L6G3TKkq4APPDphNnC_id6LHNHaPH2EsTPQmS6k5CCRABHw@mail.gmail.com>
	<CAE9L6G1psHHFSAVznyHWdk8V8vqS4uKf=c+XqELq3rjmLmieCA@mail.gmail.com>
	<CAE9L6G1_kjhej7qLefd3U0ssjcoz4dNe8Bj4nNVKm9+qARhU+Q@mail.gmail.com>
	<CAE9L6G3hXo6DtQmA1BZ_mC=4mtvDhwkc3_c-DVtM6s9gTxKy0g@mail.gmail.com>
	<CAE9L6G0vAMLOiq74FF7_yFMtrdbsbck+4jOeGsELcqrkcjn4EA@mail.gmail.com>
	<CAE9L6G2=B7Vr_-t4xCUsgWFLKQtGRVXaAzRzh3OS4JeKV+JiUQ@mail.gmail.com>
	<CAE9L6G0E4YAWqVuJkqWZN15UphwfN-gNd87UT_7Fz52o_N8VZA@mail.gmail.com>
Message-ID: <CAE9L6G1uFoc+yWqdFLA5WEChwi1FDpoRbi7Ab6WaGFDBj1gnsg@mail.gmail.com>

Hi all,
We are progressing on the Apache BVal implementation of BV 2.0 and I have a
question. Taking as a concrete example,
CascadingOnContainerElementsTest#cascading_on_container_element_of_constructor_parameter_is_applied():
BarService#<init>(List) annotates the Bar element type of the List
parameter, yet the unit test appears to treat this identically to a BV < 2
@Valid List, from the perspective of the expected path nodes. I can perhaps
accept that, but if that is what is expected by the spec (I don't find this
explicitly stated, but that may be my problem), when would the built in
list element value extractor be expected to kick in and supply the <list
element> node as stated in the spec, and/or when would said node be
expected to show up in a path?

Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180302/819d4a21/attachment.html 

From mbenson at apache.org  Fri Mar  2 18:27:07 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 2 Mar 2018 17:27:07 -0600
Subject: [bv-dev] Value extractors and the TCK
In-Reply-To: <CAE9L6G1uFoc+yWqdFLA5WEChwi1FDpoRbi7Ab6WaGFDBj1gnsg@mail.gmail.com>
References: <CAE9L6G1znR=qiNd9Kxgo31bm1Aqf07bP=q7t+ACvAFvx+YU+iw@mail.gmail.com>
	<CAE9L6G01v+u+MkzoMOk0QqbieOs85mnterbZtkSaW5=Xv2F58g@mail.gmail.com>
	<CAE9L6G21sNj+iy9bSOsOLBvbpuk9tjdhC=BaCyYhA7yaJTb33g@mail.gmail.com>
	<CAE9L6G3TH55Kw7B25bbsK=zkjFxDELUoFkt4HwYkSHPMCbc6hg@mail.gmail.com>
	<CAE9L6G3y44isEXYJDu7C1cfosMWyX1KCK0X6F1_Aebw+WpVmZg@mail.gmail.com>
	<CAE9L6G1saxg=Q2MAp4KhHWTkauJgCmPi5sNZuDvd-E9NF+jx7g@mail.gmail.com>
	<CAE9L6G2tP38DHXJN+KPPzc9UDreno6AOq9fzo2tZj3N_tSmu=Q@mail.gmail.com>
	<CAE9L6G0X0pCq1rdPnQ78orGdVu6pgJWK4qdV4xyTcwNpG6ouJA@mail.gmail.com>
	<CAE9L6G37f+xEvDJVg3foamxBxWG4KnUEUcG-_RL7qGOB3W32Qg@mail.gmail.com>
	<CAE9L6G14pcRkVVH2bgZ-_T5t8i1ha2-OaKjhcdcQa528E+hF=Q@mail.gmail.com>
	<CAE9L6G3TKkq4APPDphNnC_id6LHNHaPH2EsTPQmS6k5CCRABHw@mail.gmail.com>
	<CAE9L6G1psHHFSAVznyHWdk8V8vqS4uKf=c+XqELq3rjmLmieCA@mail.gmail.com>
	<CAE9L6G1_kjhej7qLefd3U0ssjcoz4dNe8Bj4nNVKm9+qARhU+Q@mail.gmail.com>
	<CAE9L6G3hXo6DtQmA1BZ_mC=4mtvDhwkc3_c-DVtM6s9gTxKy0g@mail.gmail.com>
	<CAE9L6G0vAMLOiq74FF7_yFMtrdbsbck+4jOeGsELcqrkcjn4EA@mail.gmail.com>
	<CAE9L6G2=B7Vr_-t4xCUsgWFLKQtGRVXaAzRzh3OS4JeKV+JiUQ@mail.gmail.com>
	<CAE9L6G0E4YAWqVuJkqWZN15UphwfN-gNd87UT_7Fz52o_N8VZA@mail.gmail.com>
	<CAE9L6G1uFoc+yWqdFLA5WEChwi1FDpoRbi7Ab6WaGFDBj1gnsg@mail.gmail.com>
Message-ID: <CAE9L6G0PtRaVS2+7bOqH_wqaY0RpmyiCaY+Sm2Lbs1Fnw0xY8g@mail.gmail.com>

Hmm, I think I am seeing the difference. The value extractor node would
show up for constraints validated directly against the container element,
then I'm extrapolating that legacy containers would cascade validation as
prior to BV 2 and thus elide this node. Can anyone confirm this
interpretation, or better yet show it to me in the spec?

Thanks,
Matt

On Mar 2, 2018 5:17 PM, "Matt Benson" <mbenson at apache.org> wrote:

> Hi all,
> We are progressing on the Apache BVal implementation of BV 2.0 and I have
> a question. Taking as a concrete example, CascadingOnContainerElementsTe
> st#cascading_on_container_element_of_constructor_parameter_is_applied():
> BarService#<init>(List) annotates the Bar element type of the List
> parameter, yet the unit test appears to treat this identically to a BV < 2
> @Valid List, from the perspective of the expected path nodes. I can perhaps
> accept that, but if that is what is expected by the spec (I don't find this
> explicitly stated, but that may be my problem), when would the built in
> list element value extractor be expected to kick in and supply the <list
> element> node as stated in the spec, and/or when would said node be
> expected to show up in a path?
>
> Thanks,
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180302/c1ae89aa/attachment-0001.html 

From gunnar at hibernate.org  Sat Mar  3 02:48:58 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 3 Mar 2018 08:48:58 +0100
Subject: [bv-dev] Value extractors and the TCK
In-Reply-To: <CAE9L6G0PtRaVS2+7bOqH_wqaY0RpmyiCaY+Sm2Lbs1Fnw0xY8g@mail.gmail.com>
References: <CAE9L6G1znR=qiNd9Kxgo31bm1Aqf07bP=q7t+ACvAFvx+YU+iw@mail.gmail.com>
	<CAE9L6G01v+u+MkzoMOk0QqbieOs85mnterbZtkSaW5=Xv2F58g@mail.gmail.com>
	<CAE9L6G21sNj+iy9bSOsOLBvbpuk9tjdhC=BaCyYhA7yaJTb33g@mail.gmail.com>
	<CAE9L6G3TH55Kw7B25bbsK=zkjFxDELUoFkt4HwYkSHPMCbc6hg@mail.gmail.com>
	<CAE9L6G3y44isEXYJDu7C1cfosMWyX1KCK0X6F1_Aebw+WpVmZg@mail.gmail.com>
	<CAE9L6G1saxg=Q2MAp4KhHWTkauJgCmPi5sNZuDvd-E9NF+jx7g@mail.gmail.com>
	<CAE9L6G2tP38DHXJN+KPPzc9UDreno6AOq9fzo2tZj3N_tSmu=Q@mail.gmail.com>
	<CAE9L6G0X0pCq1rdPnQ78orGdVu6pgJWK4qdV4xyTcwNpG6ouJA@mail.gmail.com>
	<CAE9L6G37f+xEvDJVg3foamxBxWG4KnUEUcG-_RL7qGOB3W32Qg@mail.gmail.com>
	<CAE9L6G14pcRkVVH2bgZ-_T5t8i1ha2-OaKjhcdcQa528E+hF=Q@mail.gmail.com>
	<CAE9L6G3TKkq4APPDphNnC_id6LHNHaPH2EsTPQmS6k5CCRABHw@mail.gmail.com>
	<CAE9L6G1psHHFSAVznyHWdk8V8vqS4uKf=c+XqELq3rjmLmieCA@mail.gmail.com>
	<CAE9L6G1_kjhej7qLefd3U0ssjcoz4dNe8Bj4nNVKm9+qARhU+Q@mail.gmail.com>
	<CAE9L6G3hXo6DtQmA1BZ_mC=4mtvDhwkc3_c-DVtM6s9gTxKy0g@mail.gmail.com>
	<CAE9L6G0vAMLOiq74FF7_yFMtrdbsbck+4jOeGsELcqrkcjn4EA@mail.gmail.com>
	<CAE9L6G2=B7Vr_-t4xCUsgWFLKQtGRVXaAzRzh3OS4JeKV+JiUQ@mail.gmail.com>
	<CAE9L6G0E4YAWqVuJkqWZN15UphwfN-gNd87UT_7Fz52o_N8VZA@mail.gmail.com>
	<CAE9L6G1uFoc+yWqdFLA5WEChwi1FDpoRbi7Ab6WaGFDBj1gnsg@mail.gmail.com>
	<CAE9L6G0PtRaVS2+7bOqH_wqaY0RpmyiCaY+Sm2Lbs1Fnw0xY8g@mail.gmail.com>
Message-ID: <CADGJaX9iifSRM8iOBkm632iKq=yC5+TduwhLekA9QVmH83Reaw@mail.gmail.com>

Hi Matt,

Great to hear that you're progressing with your implementation!

> Can anyone confirm this interpretation, or better yet show it to me in
the spec?

Yes, you're on the right path ;)

There are two separate aspects here: a) invocation of value extractors in
order to obtain a container's elements and b) rules for constructing
property paths.

On a), value extractors are called to cascade into containers when
processing @Valid (where 2.0 generalizes the 1.1 notion of cascaded
validation, see [1]) and when processing container element constraints
(e.g. List<@Positive Integer>).

On b), the rules are described in [2]. Specifically:

    "If a parameter ... of a ... constructor is traversed:
        * a ... ConstructorNode object is added to the Path
        * ... a ParameterNode object is added to the Path
        * if the parameter ... is a List or an array, the following
          Node object added contains the index value in getIndex().

And:

    "For a container element constraint:
        * if the corresponding value extractor has specified a node name
when
          calling one of the receiver methods, a ContainerElementNode object
          with that name is added to the Path"

I.e. you'll see path nodes with the name returned by a value extractor in
the second case, but not the first. One more case where you will see a node
with that name, is nested cascaded validation (Map<String, List<@Valid
Address>>).

And finally, no node will be appended if the extractor doesn't provide a
node name. This is to suppress addition of a node for wrapper-style
containers such as Optional<@Positive Integer> or @Positive OptionalInt.

Hth,

--Gunnar

[1]
http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationprocess-requirements-graphvalidation
[2] http://beanvalidation.org/2.0/spec/#validationapi-constraintviolation


2018-03-03 0:27 GMT+01:00 Matt Benson <mbenson at apache.org>:

> Hmm, I think I am seeing the difference. The value extractor node would
> show up for constraints validated directly against the container element,
> then I'm extrapolating that legacy containers would cascade validation as
> prior to BV 2 and thus elide this node. Can anyone confirm this
> interpretation, or better yet show it to me in the spec?
>
> Thanks,
> Matt
>
> On Mar 2, 2018 5:17 PM, "Matt Benson" <mbenson at apache.org> wrote:
>
>> Hi all,
>> We are progressing on the Apache BVal implementation of BV 2.0 and I have
>> a question. Taking as a concrete example, CascadingOnContainerElementsTe
>> st#cascading_on_container_element_of_constructor_parameter_is_applied():
>> BarService#<init>(List) annotates the Bar element type of the List
>> parameter, yet the unit test appears to treat this identically to a BV < 2
>> @Valid List, from the perspective of the expected path nodes. I can perhaps
>> accept that, but if that is what is expected by the spec (I don't find this
>> explicitly stated, but that may be my problem), when would the built in
>> list element value extractor be expected to kick in and supply the <list
>> element> node as stated in the spec, and/or when would said node be
>> expected to show up in a path?
>>
>> Thanks,
>> 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/20180303/11fd09c7/attachment.html 

From mbenson at apache.org  Mon Mar 12 19:18:57 2018
From: mbenson at apache.org (Matt Benson)
Date: Mon, 12 Mar 2018 18:18:57 -0500
Subject: [bv-dev] TCK: LegacyValidOnContainerCascadingTest
In-Reply-To: <CAE9L6G1cM3V33hD4OYS-x=B40KFkMdMPiu3QSU1n1yv=Y_mwnQ@mail.gmail.com>
References: <CAE9L6G0kyLCck574GsD0fUd3a-K_u_2-ht1ydPC4m-bR3YD_yQ@mail.gmail.com>
	<CAE9L6G3XJPg=+wY-6-bBUqksPGHynEBfWcWbx6Z=KT4G2vrgHg@mail.gmail.com>
	<CAE9L6G26_6gsKdSxufHhnY9ezS4sPE1YiwVJk0bhya5AgQ_krQ@mail.gmail.com>
	<CAE9L6G3bwfw=xMZRj095m73AnJU_1jyTS=xJFSidyy=wLvWniw@mail.gmail.com>
	<CAE9L6G0jbkWuD_+X8A-scgGvcvqg7-oeLDfvNeaPzEZO0w846w@mail.gmail.com>
	<CAE9L6G3SbVyozGL6eMy8X7B9g+CiDR2g3F07cfeVqKGxFwGJyA@mail.gmail.com>
	<CAE9L6G2yRaTLM0LXMZUKVt3HBusB4CHmzUcJjybKpBJTfmOK+Q@mail.gmail.com>
	<CAE9L6G2=T5YPGYKqj_iiudk6DDgv5=sD5q04onshzkKxHYD0EQ@mail.gmail.com>
	<CAE9L6G3aj2djEmwNWG6JUAB2GtvTBQvC0rrQRZkGOzPmP324SQ@mail.gmail.com>
	<CAE9L6G2oMnrsWQTa9=YNCACa-DwGTpdSOVikX8krnT0jzf3u4Q@mail.gmail.com>
	<CAE9L6G2AGqMnn6GFDW6xijmbW32NenEg5mLobFnnvX=rqaf5Jg@mail.gmail.com>
	<CAE9L6G340Hrvj86DbSK0Rd_Fq2HUOi6s1M921DqGaGikVhQnRw@mail.gmail.com>
	<CAE9L6G04=k5i1kyzt3Joy6=L3Q8L2sj7M3USVxwb1OE1dVhTdA@mail.gmail.com>
	<CAE9L6G1fmAusFbPYLsmiX_TXyztivxpbxvoPgVno6+Reoxk+bA@mail.gmail.com>
	<CAE9L6G2z--h5xx0HcjtTRGxTWSowsH8X63E3Et3-GMgPb==8bA@mail.gmail.com>
	<CAE9L6G3OKRmYtUWg45Dy17VP8zXz=ZsNzCVomQVzuOWZwNCOqA@mail.gmail.com>
	<CAE9L6G3Y5UFa8k_CTBgKPWWZKDoOBpPtVXZqXr9jAEoQo+1U-w@mail.gmail.com>
	<CAE9L6G2cpSjrBP13Ve5RcjPooLJgT2LVQCnDWeCdpp0QJaQxkA@mail.gmail.com>
	<CAE9L6G2kCZM9GqWQO1_CK_tN1QUYUupY0TFt=QbwwRyTGVDKxA@mail.gmail.com>
	<CAE9L6G0cWh9nLB7BYw2m=0D2CF6jdURz7F779Rv_SyE+s1qJog@mail.gmail.com>
	<CAE9L6G22od8JNsp7ER1DDv--2rbMxD+cgtwwxO7FMBECFox=Lw@mail.gmail.com>
	<CAE9L6G2fS=VtE3mO-eoAjLne4ot2HKYVE3PoaH_Fy7sNJw=o3Q@mail.gmail.com>
	<CAE9L6G2Vw27Y9ZiYF-fsggMUp+RdVRKThU_D_PoBvfoLK7Lzfg@mail.gmail.com>
	<CAE9L6G2iCumnQ5QhQGYYVwLVXjPrmPLNmEVZyawVZiSgkpeHCA@mail.gmail.com>
	<CAE9L6G1cM3V33hD4OYS-x=B40KFkMdMPiu3QSU1n1yv=Y_mwnQ@mail.gmail.com>
Message-ID: <CAE9L6G2CBypcokiq6Lpva_Fwd8dQO1ERM8qDibUsC8DXk5gutA@mail.gmail.com>

Hi all,
This issue could be similar to my last one. On
#testValidOnListAndOnTypeArgumentWithGroupConversions() the expectation is
the single violation on visitors[0].name with the Default group. My
implementation converts Default to ExtendedChecks1, cascades the legacy
list elements, then converts ExtendedChecks1 to ExtendedChecks2 when
cascading the type parameters. I end up with violations on
visitors[0].extended1 and visitors[0].extended2 . I don't see any
interpretation that seems to justify triggering the violation on the
Default group. The test points to spec section 5.1.3 but a reread of that
section does nothing for me here. Help would be appreciated here.

Next, can anyone explain the intent of @SpecAssertion#id() ?

Finally, this is the last TCK test I have failing, but next I have 928
tests being skipped. Our team has yet to figure out the mechanism by which
these tests are being skipped and we'd be glad for some help here as well.

Thanks all,
Matt and the Apache BVal team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180312/14d4f789/attachment.html 

From guillaume.smet at gmail.com  Tue Mar 13 06:30:14 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 13 Mar 2018 11:30:14 +0100
Subject: [bv-dev] TCK: LegacyValidOnContainerCascadingTest
In-Reply-To: <CAE9L6G2CBypcokiq6Lpva_Fwd8dQO1ERM8qDibUsC8DXk5gutA@mail.gmail.com>
References: <CAE9L6G0kyLCck574GsD0fUd3a-K_u_2-ht1ydPC4m-bR3YD_yQ@mail.gmail.com>
	<CAE9L6G3XJPg=+wY-6-bBUqksPGHynEBfWcWbx6Z=KT4G2vrgHg@mail.gmail.com>
	<CAE9L6G26_6gsKdSxufHhnY9ezS4sPE1YiwVJk0bhya5AgQ_krQ@mail.gmail.com>
	<CAE9L6G3bwfw=xMZRj095m73AnJU_1jyTS=xJFSidyy=wLvWniw@mail.gmail.com>
	<CAE9L6G0jbkWuD_+X8A-scgGvcvqg7-oeLDfvNeaPzEZO0w846w@mail.gmail.com>
	<CAE9L6G3SbVyozGL6eMy8X7B9g+CiDR2g3F07cfeVqKGxFwGJyA@mail.gmail.com>
	<CAE9L6G2yRaTLM0LXMZUKVt3HBusB4CHmzUcJjybKpBJTfmOK+Q@mail.gmail.com>
	<CAE9L6G2=T5YPGYKqj_iiudk6DDgv5=sD5q04onshzkKxHYD0EQ@mail.gmail.com>
	<CAE9L6G3aj2djEmwNWG6JUAB2GtvTBQvC0rrQRZkGOzPmP324SQ@mail.gmail.com>
	<CAE9L6G2oMnrsWQTa9=YNCACa-DwGTpdSOVikX8krnT0jzf3u4Q@mail.gmail.com>
	<CAE9L6G2AGqMnn6GFDW6xijmbW32NenEg5mLobFnnvX=rqaf5Jg@mail.gmail.com>
	<CAE9L6G340Hrvj86DbSK0Rd_Fq2HUOi6s1M921DqGaGikVhQnRw@mail.gmail.com>
	<CAE9L6G04=k5i1kyzt3Joy6=L3Q8L2sj7M3USVxwb1OE1dVhTdA@mail.gmail.com>
	<CAE9L6G1fmAusFbPYLsmiX_TXyztivxpbxvoPgVno6+Reoxk+bA@mail.gmail.com>
	<CAE9L6G2z--h5xx0HcjtTRGxTWSowsH8X63E3Et3-GMgPb==8bA@mail.gmail.com>
	<CAE9L6G3OKRmYtUWg45Dy17VP8zXz=ZsNzCVomQVzuOWZwNCOqA@mail.gmail.com>
	<CAE9L6G3Y5UFa8k_CTBgKPWWZKDoOBpPtVXZqXr9jAEoQo+1U-w@mail.gmail.com>
	<CAE9L6G2cpSjrBP13Ve5RcjPooLJgT2LVQCnDWeCdpp0QJaQxkA@mail.gmail.com>
	<CAE9L6G2kCZM9GqWQO1_CK_tN1QUYUupY0TFt=QbwwRyTGVDKxA@mail.gmail.com>
	<CAE9L6G0cWh9nLB7BYw2m=0D2CF6jdURz7F779Rv_SyE+s1qJog@mail.gmail.com>
	<CAE9L6G22od8JNsp7ER1DDv--2rbMxD+cgtwwxO7FMBECFox=Lw@mail.gmail.com>
	<CAE9L6G2fS=VtE3mO-eoAjLne4ot2HKYVE3PoaH_Fy7sNJw=o3Q@mail.gmail.com>
	<CAE9L6G2Vw27Y9ZiYF-fsggMUp+RdVRKThU_D_PoBvfoLK7Lzfg@mail.gmail.com>
	<CAE9L6G2iCumnQ5QhQGYYVwLVXjPrmPLNmEVZyawVZiSgkpeHCA@mail.gmail.com>
	<CAE9L6G1cM3V33hD4OYS-x=B40KFkMdMPiu3QSU1n1yv=Y_mwnQ@mail.gmail.com>
	<CAE9L6G2CBypcokiq6Lpva_Fwd8dQO1ERM8qDibUsC8DXk5gutA@mail.gmail.com>
Message-ID: <CALt0+o8H7SOGkG+3t7H3MXF-qMKAAEXQPQu_4OyFx1KAHmEztQ@mail.gmail.com>

Hi Matt,

On Tue, Mar 13, 2018 at 12:18 AM, Matt Benson <mbenson at apache.org> wrote:

> Hi all,
> This issue could be similar to my last one. On #
> testValidOnListAndOnTypeArgumentWithGroupConversions() the expectation is
> the single violation on visitors[0].name with the Default group. My
> implementation converts Default to ExtendedChecks1, cascades the legacy
> list elements, then converts ExtendedChecks1 to ExtendedChecks2 when
> cascading the type parameters. I end up with violations on
> visitors[0].extended1 and visitors[0].extended2 . I don't see any
> interpretation that seems to justify triggering the violation on the
> Default group. The test points to spec section 5.1.3 but a reread of that
> section does nothing for me here. Help would be appreciated here.
>

I think you're right. I remember some discussion with Gunnar about this
specific subject when we decided to only keep the group conversion of the
type arguments but it's definitely not specified as is in the spec.

Considering it's a corner case that is explicitly not recommended, I think
we should simply drop this test and keep the behavior undefined for now and
do better in the next revision of the spec.

Reading again this part, I think the "(in order to prevent the container
elements from being validated twice)" part should also go away as it's at
the discretion of the implementation to validate them twice or once
(especially given we have some infinite loop detection going on to prevent
circular dependencies that might intervene and IIRC we also don't want
constraints to be enforced twice).

Gunnar is at a conference right now, we'll discuss that more in depth when
he's back but I'd say don't worry about this test.

About the TCK tests being ignored, could you please open another thread
with more details on your TCK setup (pointers to the code and how you run
it would be nice) so we don't pollute this one?

Thanks.

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180313/219d58a1/attachment-0001.html 

From mbenson at apache.org  Tue Mar 13 11:42:42 2018
From: mbenson at apache.org (Matt Benson)
Date: Tue, 13 Mar 2018 10:42:42 -0500
Subject: [bv-dev] Skipped TCK tests
Message-ID: <CAE9L6G1PnEp+Fd9FkTMBBsuHeKz=0SMUC0sF3OaW2--SJLs7cA@mail.gmail.com>

As mentioned elsewhere, the Apache BVal implementation of BV2 (which
includes an extensive rewrite of much of our supporting code) is
proceeding but we are seeing a large number of skipped tests. Our
configuration looks very much like the Maven example pointed to by the
TCK reference guide and can be observed at [1]. If anyone has any tips
on how to determine what's causing so many skipped tests, they would
be much appreciated.

Thanks,
Matt & team
[1] https://github.com/apache/bval/blob/bv2/bval-tck/pom.xml

From guillaume.smet at gmail.com  Tue Mar 13 12:51:28 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 13 Mar 2018 17:51:28 +0100
Subject: [bv-dev] Skipped TCK tests
In-Reply-To: <CAE9L6G1PnEp+Fd9FkTMBBsuHeKz=0SMUC0sF3OaW2--SJLs7cA@mail.gmail.com>
References: <CAE9L6G1PnEp+Fd9FkTMBBsuHeKz=0SMUC0sF3OaW2--SJLs7cA@mail.gmail.com>
Message-ID: <CALt0+o_FBhoo56Ysh+742OzW=vVoecLx2OSyHO3UK2GQ+kP0hw@mail.gmail.com>

On Tue, Mar 13, 2018 at 4:42 PM, Matt Benson <mbenson at apache.org> wrote:

> As mentioned elsewhere, the Apache BVal implementation of BV2 (which
> includes an extensive rewrite of much of our supporting code) is
> proceeding but we are seeing a large number of skipped tests. Our
> configuration looks very much like the Maven example pointed to by the
> TCK reference guide and can be observed at [1]. If anyone has any tips
> on how to determine what's causing so many skipped tests, they would
> be much appreciated.
>

OK, as far as I can see it skips all of the tests here, except the first
one.

I wonder if the test suite is skipped due to this issue:
arquillianBeforeClass(org.hibernate.beanvalidation.tck.
tests.xmlconfiguration.MissingClassNameOnBeanNodeTest)  Time elapsed: 0.292
s  <<< FAILURE!
org.apache.webbeans.exception.WebBeansDeploymentException:

I know that sometimes I have the same issue with the TCK for HV, when a
given test fails it decides to skip all the tests after it, and I wonder if
a failure in arquillianBeforeClass might not be a trigger for it.

Adding the following exclusion <exclude
name="org.hibernate.beanvalidation.tck.tests.xmlconfiguration"/> in the
suite file makes it run a few more tests so I think this might be a valid
assumption.

HTH.

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

From mbenson at apache.org  Tue Mar 13 13:54:12 2018
From: mbenson at apache.org (Matt Benson)
Date: Tue, 13 Mar 2018 12:54:12 -0500
Subject: [bv-dev] Skipped TCK tests
In-Reply-To: <CALt0+o_FBhoo56Ysh+742OzW=vVoecLx2OSyHO3UK2GQ+kP0hw@mail.gmail.com>
References: <CAE9L6G1PnEp+Fd9FkTMBBsuHeKz=0SMUC0sF3OaW2--SJLs7cA@mail.gmail.com>
	<CALt0+o_FBhoo56Ysh+742OzW=vVoecLx2OSyHO3UK2GQ+kP0hw@mail.gmail.com>
Message-ID: <CAE9L6G2HL_PGv+mh6aqsy-oKCmZdySJ5Dt70C5aNY4NgPPQoGQ@mail.gmail.com>

Thanks, Guillaume... I have been chasing down the same path so we'll
see what happens. :)

Matt

On Tue, Mar 13, 2018 at 11:51 AM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> On Tue, Mar 13, 2018 at 4:42 PM, Matt Benson <mbenson at apache.org> wrote:
>>
>> As mentioned elsewhere, the Apache BVal implementation of BV2 (which
>> includes an extensive rewrite of much of our supporting code) is
>> proceeding but we are seeing a large number of skipped tests. Our
>> configuration looks very much like the Maven example pointed to by the
>> TCK reference guide and can be observed at [1]. If anyone has any tips
>> on how to determine what's causing so many skipped tests, they would
>> be much appreciated.
>
>
> OK, as far as I can see it skips all of the tests here, except the first
> one.
>
> I wonder if the test suite is skipped due to this issue:
> arquillianBeforeClass(org.hibernate.beanvalidation.tck.tests.xmlconfiguration.MissingClassNameOnBeanNodeTest)
> Time elapsed: 0.292 s  <<< FAILURE!
> org.apache.webbeans.exception.WebBeansDeploymentException:
>
> I know that sometimes I have the same issue with the TCK for HV, when a
> given test fails it decides to skip all the tests after it, and I wonder if
> a failure in arquillianBeforeClass might not be a trigger for it.
>
> Adding the following exclusion <exclude
> name="org.hibernate.beanvalidation.tck.tests.xmlconfiguration"/> in the
> suite file makes it run a few more tests so I think this might be a valid
> assumption.
>
> HTH.
>
> --
> Guillaume
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From mbenson at apache.org  Fri Mar 16 14:39:37 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 16 Mar 2018 13:39:37 -0500
Subject: [bv-dev] TCK expects tolerance of mismatched constraint and
	constraint validator
In-Reply-To: <CAE9L6G09fe8mZNxJOtFQn51_D7nBnjb=LyhHuuaXv3eh43Wc0A@mail.gmail.com>
References: <CAE9L6G347djWFpx_zc1f+y-x6Nx20hrdOTJ4DAN5e9CjDNrV_A@mail.gmail.com>
	<CAE9L6G09fe8mZNxJOtFQn51_D7nBnjb=LyhHuuaXv3eh43Wc0A@mail.gmail.com>
Message-ID: <CAE9L6G1ETHx5kVPdsxOp5jja5+Oihi+4NKdn2Yj5KxurYz5TiA@mail.gmail.com>

FrenchAddressListContainer defines @FrenchZipcodeListContainer as a
constraint that is validated by FrenchZipcodeConstraintValidator, but that
class declares its constraint type parameter as @FrenchZipCode. Because
that CV type does not override #init() this presumably works in the RI, and
the spec is a bit vague on this point, but the interface definition
describes type parameter A as "the annotation type handled by an
implementation." The spec section ConstraintValidator resolution algorithm
also correlates constraint A to the type parameters of the
ConstraintValidators described in the resolution rules. Finally, I don't
see anything under "What's new in 2.0" to indicate that this should be a
legal constraint definition.

Can I get a ruling? :)

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

From mbenson at apache.org  Fri Mar 16 14:44:35 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 16 Mar 2018 13:44:35 -0500
Subject: [bv-dev] TCK expects tolerance of mismatched constraint and
	constraint validator
In-Reply-To: <CAE9L6G1ETHx5kVPdsxOp5jja5+Oihi+4NKdn2Yj5KxurYz5TiA@mail.gmail.com>
References: <CAE9L6G347djWFpx_zc1f+y-x6Nx20hrdOTJ4DAN5e9CjDNrV_A@mail.gmail.com>
	<CAE9L6G09fe8mZNxJOtFQn51_D7nBnjb=LyhHuuaXv3eh43Wc0A@mail.gmail.com>
	<CAE9L6G1ETHx5kVPdsxOp5jja5+Oihi+4NKdn2Yj5KxurYz5TiA@mail.gmail.com>
Message-ID: <CAE9L6G1DQqUf9E_LmZcEDD+gXYuw68E7PfkN3FUmig16j39WFQ@mail.gmail.com>

On Mar 16, 2018 1:39 PM, "Matt Benson" <mbenson at apache.org> wrote:

FrenchAddressListContainer defines @FrenchZipcodeListContainer as a
constraint that is validated by FrenchZipcodeConstraintValidator, but that
class declares its constraint type parameter as @FrenchZipCode.


Same for FrenchZipcodeMixDirectAnnotationAndListContainer.

Because

that CV type does not override #init() this presumably works in the RI, and
the spec is a bit vague on this point, but the interface definition
describes type parameter A as "the annotation type handled by an
implementation." The spec section ConstraintValidator resolution algorithm
also correlates constraint A to the type parameters of the
ConstraintValidators described in the resolution rules. Finally, I don't
see anything under "What's new in 2.0" to indicate that this should be a
legal constraint definition.

Can I get a ruling? :)

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

From mbenson at apache.org  Fri Mar 16 15:13:59 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 16 Mar 2018 14:13:59 -0500
Subject: [bv-dev] TCK expects constraint definition exception but specifies
 illegal method arguments first
Message-ID: <CAE9L6G1Qr3CJjHWFoOmJbRryyhLsFPDoRyWje6M=19DJ1_ftkA@mail.gmail.com>

InConstraintCompositionTest, tests
#testMixedConstraintTargetsInComposedAndComposingConstraintsCauseException()
and #testMixedConstraintTargetsInComposingConstraintsCauseException()
expect a ConstraintDefinitionException, but both attempt to validate an
empty Object array for a method whose signature is (int). However, the
methods of ExecutableValidator all declare that an IllegalArgumentException
will be thrown if any parameters to *those* methods do not match. I take
this to mean that a parameter array should be of the same length and
respectively assignable types to the parameter types supported by a method
or constructor, and similarly that a validated return value should actually
be a value that could have been returned by a given method or constructor.
I don't see that there is any specification as to when these
IllegalArgumentExceptions should be thrown, but it seems to me that you
would typically validate the objects you have locally before going off to
look up and validate the metadata for the appropriate bean type. I would
request that the parameter arrays used in these tests be updated to
something actually compatible with the methods in question, which could
only serve to further the emphasis on the actual spec item being verified
by the test method in question.

Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180316/75d9c02b/attachment.html 

From mbenson at apache.org  Fri Mar 16 15:18:08 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 16 Mar 2018 14:18:08 -0500
Subject: [bv-dev] TCK expects tolerance of mismatched constraint and
	constraint validator
In-Reply-To: <CAE9L6G1DQqUf9E_LmZcEDD+gXYuw68E7PfkN3FUmig16j39WFQ@mail.gmail.com>
References: <CAE9L6G347djWFpx_zc1f+y-x6Nx20hrdOTJ4DAN5e9CjDNrV_A@mail.gmail.com>
	<CAE9L6G09fe8mZNxJOtFQn51_D7nBnjb=LyhHuuaXv3eh43Wc0A@mail.gmail.com>
	<CAE9L6G1ETHx5kVPdsxOp5jja5+Oihi+4NKdn2Yj5KxurYz5TiA@mail.gmail.com>
	<CAE9L6G1DQqUf9E_LmZcEDD+gXYuw68E7PfkN3FUmig16j39WFQ@mail.gmail.com>
Message-ID: <CAE9L6G3GudoshyhKx-Ufk7UJNy0DMue_5ZfCAOHfH5O=Vu+Jbg@mail.gmail.com>

Similarly, ZeroConstraintValidator is declared as targeting @Negative.

On Mar 16, 2018 1:44 PM, "Matt Benson" <mbenson at apache.org> wrote:

> On Mar 16, 2018 1:39 PM, "Matt Benson" <mbenson at apache.org> wrote:
>
> FrenchAddressListContainer defines @FrenchZipcodeListContainer as a
> constraint that is validated by FrenchZipcodeConstraintValidator, but
> that class declares its constraint type parameter as @FrenchZipCode.
>
>
> Same for FrenchZipcodeMixDirectAnnotationAndListContainer.
>
> Because
>
> that CV type does not override #init() this presumably works in the RI,
> and the spec is a bit vague on this point, but the interface definition
> describes type parameter A as "the annotation type handled by an
> implementation." The spec section ConstraintValidator resolution algorithm
> also correlates constraint A to the type parameters of the
> ConstraintValidators described in the resolution rules. Finally, I don't
> see anything under "What's new in 2.0" to indicate that this should be a
> legal constraint definition.
>
> Can I get a ruling? :)
>
> Matt
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180316/2ef22071/attachment-0001.html 

From gunnar at hibernate.org  Mon Mar 19 06:39:08 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 19 Mar 2018 11:39:08 +0100
Subject: [bv-dev] TCK: LegacyValidOnContainerCascadingTest
In-Reply-To: <CALt0+o8H7SOGkG+3t7H3MXF-qMKAAEXQPQu_4OyFx1KAHmEztQ@mail.gmail.com>
References: <CAE9L6G0kyLCck574GsD0fUd3a-K_u_2-ht1ydPC4m-bR3YD_yQ@mail.gmail.com>
	<CAE9L6G3XJPg=+wY-6-bBUqksPGHynEBfWcWbx6Z=KT4G2vrgHg@mail.gmail.com>
	<CAE9L6G26_6gsKdSxufHhnY9ezS4sPE1YiwVJk0bhya5AgQ_krQ@mail.gmail.com>
	<CAE9L6G3bwfw=xMZRj095m73AnJU_1jyTS=xJFSidyy=wLvWniw@mail.gmail.com>
	<CAE9L6G0jbkWuD_+X8A-scgGvcvqg7-oeLDfvNeaPzEZO0w846w@mail.gmail.com>
	<CAE9L6G3SbVyozGL6eMy8X7B9g+CiDR2g3F07cfeVqKGxFwGJyA@mail.gmail.com>
	<CAE9L6G2yRaTLM0LXMZUKVt3HBusB4CHmzUcJjybKpBJTfmOK+Q@mail.gmail.com>
	<CAE9L6G2=T5YPGYKqj_iiudk6DDgv5=sD5q04onshzkKxHYD0EQ@mail.gmail.com>
	<CAE9L6G3aj2djEmwNWG6JUAB2GtvTBQvC0rrQRZkGOzPmP324SQ@mail.gmail.com>
	<CAE9L6G2oMnrsWQTa9=YNCACa-DwGTpdSOVikX8krnT0jzf3u4Q@mail.gmail.com>
	<CAE9L6G2AGqMnn6GFDW6xijmbW32NenEg5mLobFnnvX=rqaf5Jg@mail.gmail.com>
	<CAE9L6G340Hrvj86DbSK0Rd_Fq2HUOi6s1M921DqGaGikVhQnRw@mail.gmail.com>
	<CAE9L6G04=k5i1kyzt3Joy6=L3Q8L2sj7M3USVxwb1OE1dVhTdA@mail.gmail.com>
	<CAE9L6G1fmAusFbPYLsmiX_TXyztivxpbxvoPgVno6+Reoxk+bA@mail.gmail.com>
	<CAE9L6G2z--h5xx0HcjtTRGxTWSowsH8X63E3Et3-GMgPb==8bA@mail.gmail.com>
	<CAE9L6G3OKRmYtUWg45Dy17VP8zXz=ZsNzCVomQVzuOWZwNCOqA@mail.gmail.com>
	<CAE9L6G3Y5UFa8k_CTBgKPWWZKDoOBpPtVXZqXr9jAEoQo+1U-w@mail.gmail.com>
	<CAE9L6G2cpSjrBP13Ve5RcjPooLJgT2LVQCnDWeCdpp0QJaQxkA@mail.gmail.com>
	<CAE9L6G2kCZM9GqWQO1_CK_tN1QUYUupY0TFt=QbwwRyTGVDKxA@mail.gmail.com>
	<CAE9L6G0cWh9nLB7BYw2m=0D2CF6jdURz7F779Rv_SyE+s1qJog@mail.gmail.com>
	<CAE9L6G22od8JNsp7ER1DDv--2rbMxD+cgtwwxO7FMBECFox=Lw@mail.gmail.com>
	<CAE9L6G2fS=VtE3mO-eoAjLne4ot2HKYVE3PoaH_Fy7sNJw=o3Q@mail.gmail.com>
	<CAE9L6G2Vw27Y9ZiYF-fsggMUp+RdVRKThU_D_PoBvfoLK7Lzfg@mail.gmail.com>
	<CAE9L6G2iCumnQ5QhQGYYVwLVXjPrmPLNmEVZyawVZiSgkpeHCA@mail.gmail.com>
	<CAE9L6G1cM3V33hD4OYS-x=B40KFkMdMPiu3QSU1n1yv=Y_mwnQ@mail.gmail.com>
	<CAE9L6G2CBypcokiq6Lpva_Fwd8dQO1ERM8qDibUsC8DXk5gutA@mail.gmail.com>
	<CALt0+o8H7SOGkG+3t7H3MXF-qMKAAEXQPQu_4OyFx1KAHmEztQ@mail.gmail.com>
Message-ID: <CADGJaX9mdF8jPJPprZfrz6K-yrF79ujhLuAyVfgNoYA1WrBAqg@mail.gmail.com>

Hi,

2018-03-13 11:30 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:

> Hi Matt,
>
> On Tue, Mar 13, 2018 at 12:18 AM, Matt Benson <mbenson at apache.org> wrote:
>
>> Hi all,
>> This issue could be similar to my last one. On
>> #testValidOnListAndOnTypeArgumentWithGroupConversions() the expectation
>> is the single violation on visitors[0].name with the Default group. My
>> implementation converts Default to ExtendedChecks1, cascades the legacy
>> list elements, then converts ExtendedChecks1 to ExtendedChecks2 when
>> cascading the type parameters. I end up with violations on
>> visitors[0].extended1 and visitors[0].extended2 . I don't see any
>> interpretation that seems to justify triggering the violation on the
>> Default group. The test points to spec section 5.1.3 but a reread of that
>> section does nothing for me here. Help would be appreciated here.
>>
>
> I think you're right. I remember some discussion with Gunnar about this
> specific subject when we decided to only keep the group conversion of the
> type arguments but it's definitely not specified as is in the spec.
>
> Considering it's a corner case that is explicitly not recommended, I think
> we should simply drop this test and keep the behavior undefined for now and
> do better in the next revision of the spec.
>

We decided back then to not mandate any specific behaviour if both the
legacy @Valid and the type-argument @Valid are given, but indeed that fact
is not totally clear from the spec. I've logged
https://hibernate.atlassian.net/browse/BVAL-709 to clarify that this is
unspecified (unless someone truly thinks this *should* be specified).

In that light indeed the TCK test should be removed.


> Reading again this part, I think the "(in order to prevent the container
> elements from being validated twice)" part should also go away as it's at
> the discretion of the implementation to validate them twice or once
> (especially given we have some infinite loop detection going on to prevent
> circular dependencies that might intervene and IIRC we also don't want
> constraints to be enforced twice).
>

Note that this sentence is not there to state that implementations *should*
honour both @Valid. Instead it's there to say that some implementation
*may* do it, and to be sure that only one is applied, one should only give
@Valid in one place.

> Next, can anyone explain the intent of @SpecAssertion#id() ?

They are used to link the TCK tests to specific sentences/phrases from the
spec. If you build the TCK from source, you'll find a
file tests/target/coverage-report/coverage-beanvalidation.html which
contains all phrases from the spec marked as TCK-relevant, allowing you to
see the link between a test method and the related spec sentences.

In that case, though, the id marker seems off, as the referenced one is
about Set, whereas this the test is about List (not that it matters, as the
test is going away anyways now).


> Gunnar is at a conference right now, we'll discuss that more in depth when
> he's back but I'd say don't worry about this test.
>
> About the TCK tests being ignored, could you please open another thread
> with more details on your TCK setup (pointers to the code and how you run
> it would be nice) so we don't pollute this one?
>
> Thanks.
>
> --
> 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/20180319/19a712db/attachment.html 

From guillaume.smet at gmail.com  Mon Mar 19 06:47:25 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 19 Mar 2018 11:47:25 +0100
Subject: [bv-dev] TCK expects tolerance of mismatched constraint and
 constraint validator
In-Reply-To: <CAE9L6G3GudoshyhKx-Ufk7UJNy0DMue_5ZfCAOHfH5O=Vu+Jbg@mail.gmail.com>
References: <CAE9L6G347djWFpx_zc1f+y-x6Nx20hrdOTJ4DAN5e9CjDNrV_A@mail.gmail.com>
	<CAE9L6G09fe8mZNxJOtFQn51_D7nBnjb=LyhHuuaXv3eh43Wc0A@mail.gmail.com>
	<CAE9L6G1ETHx5kVPdsxOp5jja5+Oihi+4NKdn2Yj5KxurYz5TiA@mail.gmail.com>
	<CAE9L6G1DQqUf9E_LmZcEDD+gXYuw68E7PfkN3FUmig16j39WFQ@mail.gmail.com>
	<CAE9L6G3GudoshyhKx-Ufk7UJNy0DMue_5ZfCAOHfH5O=Vu+Jbg@mail.gmail.com>
Message-ID: <CALt0+o-UfcH=wmyn5ApwEPPAc_eJNfr1pBbLh2V+Wa+cbh6bmQ@mail.gmail.com>

Hi Matt,

Yes, you're right, looks like our implementation has always been too
permissive in this regard.

I think I'll make our implementation less permissive and fix the related
TCK failures. I've implemented the check in HV and AFAICS you have found
all the occurrences of this issue.

Will create a TCK issue and fix.

-- 
Guillaume

On Fri, Mar 16, 2018 at 8:18 PM, Matt Benson <mbenson at apache.org> wrote:

> Similarly, ZeroConstraintValidator is declared as targeting @Negative.
>
> On Mar 16, 2018 1:44 PM, "Matt Benson" <mbenson at apache.org> wrote:
>
>> On Mar 16, 2018 1:39 PM, "Matt Benson" <mbenson at apache.org> wrote:
>>
>> FrenchAddressListContainer defines @FrenchZipcodeListContainer as a
>> constraint that is validated by FrenchZipcodeConstraintValidator, but
>> that class declares its constraint type parameter as @FrenchZipCode.
>>
>>
>> Same for FrenchZipcodeMixDirectAnnotationAndListContainer.
>>
>> Because
>>
>> that CV type does not override #init() this presumably works in the RI,
>> and the spec is a bit vague on this point, but the interface definition
>> describes type parameter A as "the annotation type handled by an
>> implementation." The spec section ConstraintValidator resolution algorithm
>> also correlates constraint A to the type parameters of the
>> ConstraintValidators described in the resolution rules. Finally, I don't
>> see anything under "What's new in 2.0" to indicate that this should be a
>> legal constraint definition.
>>
>> Can I get a ruling? :)
>>
>> 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/20180319/3f1f1bac/attachment.html 

From guillaume.smet at gmail.com  Mon Mar 19 07:07:09 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 19 Mar 2018 12:07:09 +0100
Subject: [bv-dev] TCK expects constraint definition exception but
 specifies illegal method arguments first
In-Reply-To: <CAE9L6G1Qr3CJjHWFoOmJbRryyhLsFPDoRyWje6M=19DJ1_ftkA@mail.gmail.com>
References: <CAE9L6G1Qr3CJjHWFoOmJbRryyhLsFPDoRyWje6M=19DJ1_ftkA@mail.gmail.com>
Message-ID: <CALt0+o8+jSq4H_KBBHTh9QqVugvx3Og7i-a9+VbvJTa-2BnE6g@mail.gmail.com>

On Fri, Mar 16, 2018 at 8:13 PM, Matt Benson <mbenson at apache.org> wrote:

> I would request that the parameter arrays used in these tests be updated
> to something actually compatible with the methods in question, which could
> only serve to further the emphasis on the actual spec item being verified
> by the test method in question.
>

Right, will fix.

https://hibernate.atlassian.net/browse/BVTCK-196

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180319/8bd02634/attachment-0001.html 

From guillaume.smet at gmail.com  Tue Mar 20 13:26:10 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 20 Mar 2018 18:26:10 +0100
Subject: [bv-dev] TCK expects constraint definition exception but
 specifies illegal method arguments first
In-Reply-To: <CALt0+o8+jSq4H_KBBHTh9QqVugvx3Og7i-a9+VbvJTa-2BnE6g@mail.gmail.com>
References: <CAE9L6G1Qr3CJjHWFoOmJbRryyhLsFPDoRyWje6M=19DJ1_ftkA@mail.gmail.com>
	<CALt0+o8+jSq4H_KBBHTh9QqVugvx3Og7i-a9+VbvJTa-2BnE6g@mail.gmail.com>
Message-ID: <CALt0+o95+aPiuPyMvr-3G37an+Wi9NtnFvwaU-21zSm80vJX8Q@mail.gmail.com>

Fixed in the 2.0 branch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180320/7a9fd66b/attachment.html 

From guillaume.smet at gmail.com  Tue Mar 20 13:26:26 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 20 Mar 2018 18:26:26 +0100
Subject: [bv-dev] TCK expects tolerance of mismatched constraint and
 constraint validator
In-Reply-To: <CALt0+o-UfcH=wmyn5ApwEPPAc_eJNfr1pBbLh2V+Wa+cbh6bmQ@mail.gmail.com>
References: <CAE9L6G347djWFpx_zc1f+y-x6Nx20hrdOTJ4DAN5e9CjDNrV_A@mail.gmail.com>
	<CAE9L6G09fe8mZNxJOtFQn51_D7nBnjb=LyhHuuaXv3eh43Wc0A@mail.gmail.com>
	<CAE9L6G1ETHx5kVPdsxOp5jja5+Oihi+4NKdn2Yj5KxurYz5TiA@mail.gmail.com>
	<CAE9L6G1DQqUf9E_LmZcEDD+gXYuw68E7PfkN3FUmig16j39WFQ@mail.gmail.com>
	<CAE9L6G3GudoshyhKx-Ufk7UJNy0DMue_5ZfCAOHfH5O=Vu+Jbg@mail.gmail.com>
	<CALt0+o-UfcH=wmyn5ApwEPPAc_eJNfr1pBbLh2V+Wa+cbh6bmQ@mail.gmail.com>
Message-ID: <CALt0+o9Ems8TcfdXNq94id029ZfmsJE3JgdWMYZp83ckLCJwXw@mail.gmail.com>

Fixed in the 2.0 branch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180320/f50adde3/attachment.html 

From guillaume.smet at gmail.com  Tue Mar 20 13:26:42 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 20 Mar 2018 18:26:42 +0100
Subject: [bv-dev] TCK: LegacyValidOnContainerCascadingTest
In-Reply-To: <CADGJaX9mdF8jPJPprZfrz6K-yrF79ujhLuAyVfgNoYA1WrBAqg@mail.gmail.com>
References: <CAE9L6G0kyLCck574GsD0fUd3a-K_u_2-ht1ydPC4m-bR3YD_yQ@mail.gmail.com>
	<CAE9L6G3XJPg=+wY-6-bBUqksPGHynEBfWcWbx6Z=KT4G2vrgHg@mail.gmail.com>
	<CAE9L6G26_6gsKdSxufHhnY9ezS4sPE1YiwVJk0bhya5AgQ_krQ@mail.gmail.com>
	<CAE9L6G3bwfw=xMZRj095m73AnJU_1jyTS=xJFSidyy=wLvWniw@mail.gmail.com>
	<CAE9L6G0jbkWuD_+X8A-scgGvcvqg7-oeLDfvNeaPzEZO0w846w@mail.gmail.com>
	<CAE9L6G3SbVyozGL6eMy8X7B9g+CiDR2g3F07cfeVqKGxFwGJyA@mail.gmail.com>
	<CAE9L6G2yRaTLM0LXMZUKVt3HBusB4CHmzUcJjybKpBJTfmOK+Q@mail.gmail.com>
	<CAE9L6G2=T5YPGYKqj_iiudk6DDgv5=sD5q04onshzkKxHYD0EQ@mail.gmail.com>
	<CAE9L6G3aj2djEmwNWG6JUAB2GtvTBQvC0rrQRZkGOzPmP324SQ@mail.gmail.com>
	<CAE9L6G2oMnrsWQTa9=YNCACa-DwGTpdSOVikX8krnT0jzf3u4Q@mail.gmail.com>
	<CAE9L6G2AGqMnn6GFDW6xijmbW32NenEg5mLobFnnvX=rqaf5Jg@mail.gmail.com>
	<CAE9L6G340Hrvj86DbSK0Rd_Fq2HUOi6s1M921DqGaGikVhQnRw@mail.gmail.com>
	<CAE9L6G04=k5i1kyzt3Joy6=L3Q8L2sj7M3USVxwb1OE1dVhTdA@mail.gmail.com>
	<CAE9L6G1fmAusFbPYLsmiX_TXyztivxpbxvoPgVno6+Reoxk+bA@mail.gmail.com>
	<CAE9L6G2z--h5xx0HcjtTRGxTWSowsH8X63E3Et3-GMgPb==8bA@mail.gmail.com>
	<CAE9L6G3OKRmYtUWg45Dy17VP8zXz=ZsNzCVomQVzuOWZwNCOqA@mail.gmail.com>
	<CAE9L6G3Y5UFa8k_CTBgKPWWZKDoOBpPtVXZqXr9jAEoQo+1U-w@mail.gmail.com>
	<CAE9L6G2cpSjrBP13Ve5RcjPooLJgT2LVQCnDWeCdpp0QJaQxkA@mail.gmail.com>
	<CAE9L6G2kCZM9GqWQO1_CK_tN1QUYUupY0TFt=QbwwRyTGVDKxA@mail.gmail.com>
	<CAE9L6G0cWh9nLB7BYw2m=0D2CF6jdURz7F779Rv_SyE+s1qJog@mail.gmail.com>
	<CAE9L6G22od8JNsp7ER1DDv--2rbMxD+cgtwwxO7FMBECFox=Lw@mail.gmail.com>
	<CAE9L6G2fS=VtE3mO-eoAjLne4ot2HKYVE3PoaH_Fy7sNJw=o3Q@mail.gmail.com>
	<CAE9L6G2Vw27Y9ZiYF-fsggMUp+RdVRKThU_D_PoBvfoLK7Lzfg@mail.gmail.com>
	<CAE9L6G2iCumnQ5QhQGYYVwLVXjPrmPLNmEVZyawVZiSgkpeHCA@mail.gmail.com>
	<CAE9L6G1cM3V33hD4OYS-x=B40KFkMdMPiu3QSU1n1yv=Y_mwnQ@mail.gmail.com>
	<CAE9L6G2CBypcokiq6Lpva_Fwd8dQO1ERM8qDibUsC8DXk5gutA@mail.gmail.com>
	<CALt0+o8H7SOGkG+3t7H3MXF-qMKAAEXQPQu_4OyFx1KAHmEztQ@mail.gmail.com>
	<CADGJaX9mdF8jPJPprZfrz6K-yrF79ujhLuAyVfgNoYA1WrBAqg@mail.gmail.com>
Message-ID: <CALt0+o_UfQtLi4ArO6XBymucVmpJ5MTzmZyWcuza1RUaNz_FSw@mail.gmail.com>

Fixed in the 2.0 branch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180320/8ee76d85/attachment.html 

From mbenson at apache.org  Wed Mar 21 16:55:23 2018
From: mbenson at apache.org (Matt Benson)
Date: Wed, 21 Mar 2018 15:55:23 -0500
Subject: [bv-dev] TCK bootstrap - ExecutableType.NONE
Message-ID: <CAE9L6G3eb=xwgvWuV7q_+ig-gk=6chr337GRcyyWo1MHP6F=oQ@mail.gmail.com>

I would challenge
BootstrapConfigurationWithValidatedExecutableTypesContainingNONETest
as defying the specification. The current version says at
http://beanvalidation.org/2.0/spec/#integration-general-executable and
in the code for ExecutableType that NONE is essentially ignored in the
presence of other types (and effectively, always). I see nothing to
dictate that NONE should be treated differently in the XML descriptor
than elsewhere.

WDYT?

Thanks,
Matt

From guillaume.smet at gmail.com  Thu Mar 22 05:17:17 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 22 Mar 2018 10:17:17 +0100
Subject: [bv-dev] TCK bootstrap - ExecutableType.NONE
In-Reply-To: <CAE9L6G3eb=xwgvWuV7q_+ig-gk=6chr337GRcyyWo1MHP6F=oQ@mail.gmail.com>
References: <CAE9L6G3eb=xwgvWuV7q_+ig-gk=6chr337GRcyyWo1MHP6F=oQ@mail.gmail.com>
Message-ID: <CALt0+o9ed+FE5bg_XiaBNSKRmQtgA6r=TEVf+xOLY6Csyt8emw@mail.gmail.com>

Hi Matt,

On Wed, Mar 21, 2018 at 9:55 PM, Matt Benson <mbenson at apache.org> wrote:

> I would challenge
> BootstrapConfigurationWithValidatedExecutableTypesContainingNONETest
> as defying the specification. The current version says at
> http://beanvalidation.org/2.0/spec/#integration-general-executable and
> in the code for ExecutableType that NONE is essentially ignored in the
> presence of other types (and effectively, always). I see nothing to
> dictate that NONE should be treated differently in the XML descriptor
> than elsewhere.
>

Outch, this one is an old one :).

The spec is very clear about the behavior of @ValidateOnExecution:
"A list containing NONE and other types of executables is equivalent to a
list containing the types of executables without NONE."

Same in the @ExecutableType javadoc:
    /**
     * None of the executables.
     * <p>
     * Note that this option is equivalent to an empty list of executable
types
     * and is present to improve readability. If {@code NONE} and other
types of executables
     * are present in a list, {@code NONE} is ignored.
     */

I can't find anything specific to the XML configuration so I suppose we
should follow the same rule.

@Gunnar does old Gunnar have any recollection of what young Gunnar did back
at the time?

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

From gunnar at hibernate.org  Thu Mar 22 06:41:00 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 22 Mar 2018 11:41:00 +0100
Subject: [bv-dev] TCK bootstrap - ExecutableType.NONE
In-Reply-To: <CALt0+o9ed+FE5bg_XiaBNSKRmQtgA6r=TEVf+xOLY6Csyt8emw@mail.gmail.com>
References: <CAE9L6G3eb=xwgvWuV7q_+ig-gk=6chr337GRcyyWo1MHP6F=oQ@mail.gmail.com>
	<CALt0+o9ed+FE5bg_XiaBNSKRmQtgA6r=TEVf+xOLY6Csyt8emw@mail.gmail.com>
Message-ID: <CADGJaX-xs+E5utzpEBZkHqRbDUs6KMoxypo_R-N1wtTC3jKcAw@mail.gmail.com>

Hi,

Yes, I agree the test isn't correct and should be adjusted. I only can
speculate why it is the way it is; perhaps we refined the semantics around
NONE at some point during the 1.1 work and then didn't adjust that test.
Working hours were a bit crazy back then ;)

I'm curious, though. Apache BVal is 1.1 certified, so you must have passed
that one before. Are you re-writing parts of the code base in the course of
implementing 2.0?

Could you also give us a heads-up of where you are in terms of passing the
TCK? We'd like to release another TCK version with the changes you pointed
out. But if there's the chance that more is coming, we'd wait a bit with
that of course.

Cheers,

--Gunnar


2018-03-22 10:17 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:

> Hi Matt,
>
> On Wed, Mar 21, 2018 at 9:55 PM, Matt Benson <mbenson at apache.org> wrote:
>
>> I would challenge
>> BootstrapConfigurationWithValidatedExecutableTypesContainingNONETest
>> as defying the specification. The current version says at
>> http://beanvalidation.org/2.0/spec/#integration-general-executable and
>> in the code for ExecutableType that NONE is essentially ignored in the
>> presence of other types (and effectively, always). I see nothing to
>> dictate that NONE should be treated differently in the XML descriptor
>> than elsewhere.
>>
>
> Outch, this one is an old one :).
>
> The spec is very clear about the behavior of @ValidateOnExecution:
> "A list containing NONE and other types of executables is equivalent to a
> list containing the types of executables without NONE."
>
> Same in the @ExecutableType javadoc:
>     /**
>      * None of the executables.
>      * <p>
>      * Note that this option is equivalent to an empty list of executable
> types
>      * and is present to improve readability. If {@code NONE} and other
> types of executables
>      * are present in a list, {@code NONE} is ignored.
>      */
>
> I can't find anything specific to the XML configuration so I suppose we
> should follow the same rule.
>
> @Gunnar does old Gunnar have any recollection of what young Gunnar did
> back at the time?
>
> --
> 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/20180322/9fdb1835/attachment-0001.html 

From mbenson at apache.org  Thu Mar 22 09:13:32 2018
From: mbenson at apache.org (Matt Benson)
Date: Thu, 22 Mar 2018 13:13:32 +0000
Subject: [bv-dev] TCK bootstrap - ExecutableType.NONE
In-Reply-To: <CADGJaX-xs+E5utzpEBZkHqRbDUs6KMoxypo_R-N1wtTC3jKcAw@mail.gmail.com>
References: <CAE9L6G3eb=xwgvWuV7q_+ig-gk=6chr337GRcyyWo1MHP6F=oQ@mail.gmail.com>
	<CALt0+o9ed+FE5bg_XiaBNSKRmQtgA6r=TEVf+xOLY6Csyt8emw@mail.gmail.com>
	<CADGJaX-xs+E5utzpEBZkHqRbDUs6KMoxypo_R-N1wtTC3jKcAw@mail.gmail.com>
Message-ID: <CAE9L6G39SHuFXtLnB6343tLUm9N1m4o-++N1enCeyrTJALPFRw@mail.gmail.com>

To answer the big question: yes, the original code donation which formed
the basis of Apache BVal more or less "bolted" BV support onto a
proprietary validation framework. 1.1 changes brought this adaptation layer
to the very brink of maintainability, and the changes required for 2.0
would just have pushed it over. I was simply unable to countenance the
inelegance of the code necessary to continue on in that vein, and at least
one other member of our team had expressed similar dissatisfaction prior to
the advent of the 2.0 spec. My approach has therefore been to rewrite
substantial portions of BVal's code to make BV its primary focus and drop
support for the legacy validation API that had underlain earlier versions
of the project. The team accepted my work as the basis for our v2
implementation and we now continue to work towards passing the current TCK.

Regarding our progress there, I don't have the precise numbers in front of
me ATM, but I would put the ballpark figure at around 2/3 complete.

Thanks,
Matt

On Thu, Mar 22, 2018, 5:41 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> Yes, I agree the test isn't correct and should be adjusted. I only can
> speculate why it is the way it is; perhaps we refined the semantics around
> NONE at some point during the 1.1 work and then didn't adjust that test.
> Working hours were a bit crazy back then ;)
>
> I'm curious, though. Apache BVal is 1.1 certified, so you must have passed
> that one before. Are you re-writing parts of the code base in the course of
> implementing 2.0?
>
> Could you also give us a heads-up of where you are in terms of passing the
> TCK? We'd like to release another TCK version with the changes you pointed
> out. But if there's the chance that more is coming, we'd wait a bit with
> that of course.
>
> Cheers,
>
> --Gunnar
>
>
> 2018-03-22 10:17 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
>
>> Hi Matt,
>>
>> On Wed, Mar 21, 2018 at 9:55 PM, Matt Benson <mbenson at apache.org> wrote:
>>
>>> I would challenge
>>> BootstrapConfigurationWithValidatedExecutableTypesContainingNONETest
>>> as defying the specification. The current version says at
>>> http://beanvalidation.org/2.0/spec/#integration-general-executable and
>>> in the code for ExecutableType that NONE is essentially ignored in the
>>> presence of other types (and effectively, always). I see nothing to
>>> dictate that NONE should be treated differently in the XML descriptor
>>> than elsewhere.
>>>
>>
>> Outch, this one is an old one :).
>>
>> The spec is very clear about the behavior of @ValidateOnExecution:
>> "A list containing NONE and other types of executables is equivalent to
>> a list containing the types of executables without NONE."
>>
>> Same in the @ExecutableType javadoc:
>>     /**
>>      * None of the executables.
>>      * <p>
>>      * Note that this option is equivalent to an empty list of executable
>> types
>>      * and is present to improve readability. If {@code NONE} and other
>> types of executables
>>      * are present in a list, {@code NONE} is ignored.
>>      */
>>
>> I can't find anything specific to the XML configuration so I suppose we
>> should follow the same rule.
>>
>> @Gunnar does old Gunnar have any recollection of what young Gunnar did
>> back at the time?
>>
>> --
>> Guillaume
>>
>> _______________________________________________
>> 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/20180322/8694a14f/attachment.html 

From guillaume.smet at gmail.com  Thu Mar 22 12:32:33 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 22 Mar 2018 17:32:33 +0100
Subject: [bv-dev] TCK bootstrap - ExecutableType.NONE
In-Reply-To: <CADGJaX-xs+E5utzpEBZkHqRbDUs6KMoxypo_R-N1wtTC3jKcAw@mail.gmail.com>
References: <CAE9L6G3eb=xwgvWuV7q_+ig-gk=6chr337GRcyyWo1MHP6F=oQ@mail.gmail.com>
	<CALt0+o9ed+FE5bg_XiaBNSKRmQtgA6r=TEVf+xOLY6Csyt8emw@mail.gmail.com>
	<CADGJaX-xs+E5utzpEBZkHqRbDUs6KMoxypo_R-N1wtTC3jKcAw@mail.gmail.com>
Message-ID: <CALt0+o-Vy=hPqxoSkEzLDSSPY2p5yvkwG=G6uGqXLMKOeihAxQ@mail.gmail.com>

On Thu, Mar 22, 2018 at 11:41 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Yes, I agree the test isn't correct and should be adjusted. I only can
> speculate why it is the way it is; perhaps we refined the semantics around
> NONE at some point during the 1.1 work and then didn't adjust that test.
> Working hours were a bit crazy back then ;)
>

https://hibernate.atlassian.net/browse/BVTCK-198

Pending PR: https://github.com/beanvalidation/beanvalidation-tck/pull/161

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

From mbenson at apache.org  Thu Mar 22 16:56:02 2018
From: mbenson at apache.org (Matt Benson)
Date: Thu, 22 Mar 2018 20:56:02 +0000
Subject: [bv-dev] Size validator for int
Message-ID: <CAE9L6G3SMOyd7Kdy4Ks9i+gNc+WkC8G7sj+cAO2LmSuqOu3Sqg@mail.gmail.com>

Several TCK tests rely on this; however I have never seen anything in the
spec to dictate that this should be covered. Having said that, it is of
course extremely easy to implement this validation for Number, so I am
happy to test this as a missing item in the spec as opposed to a problem in
the TCK.

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

From gunnar at hibernate.org  Thu Mar 22 17:10:02 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 22 Mar 2018 22:10:02 +0100
Subject: [bv-dev] Size validator for int
In-Reply-To: <CAE9L6G3SMOyd7Kdy4Ks9i+gNc+WkC8G7sj+cAO2LmSuqOu3Sqg@mail.gmail.com>
References: <CAE9L6G3SMOyd7Kdy4Ks9i+gNc+WkC8G7sj+cAO2LmSuqOu3Sqg@mail.gmail.com>
Message-ID: <CADGJaX_94ifRz9EUD7=f9qzdqd68EB-uzTqnut7wiRDRwkyiCg@mail.gmail.com>

Hi,

Do you have a list of the tests which are concerned by this?

Thanks,

--Gunnar


2018-03-22 21:56 GMT+01:00 Matt Benson <mbenson at apache.org>:

> Several TCK tests rely on this; however I have never seen anything in the
> spec to dictate that this should be covered. Having said that, it is of
> course extremely easy to implement this validation for Number, so I am
> happy to test this as a missing item in the spec as opposed to a problem in
> the TCK.
>
> 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/20180322/ce27cf4b/attachment.html 

From mbenson at apache.org  Thu Mar 22 18:12:57 2018
From: mbenson at apache.org (Matt Benson)
Date: Thu, 22 Mar 2018 22:12:57 +0000
Subject: [bv-dev] Size validator for int
In-Reply-To: <CADGJaX_94ifRz9EUD7=f9qzdqd68EB-uzTqnut7wiRDRwkyiCg@mail.gmail.com>
References: <CAE9L6G3SMOyd7Kdy4Ks9i+gNc+WkC8G7sj+cAO2LmSuqOu3Sqg@mail.gmail.com>
	<CADGJaX_94ifRz9EUD7=f9qzdqd68EB-uzTqnut7wiRDRwkyiCg@mail.gmail.com>
Message-ID: <CAE9L6G0xfooMYDkEeGd_ASTiM1r1Cqikkm8wZbAvXk_2t9UJSA@mail.gmail.com>

Hi Gunnar,
Yeah, this is weird. Elsewhere there is a test that specifically looks for
there *not* being a Size validator for int. I will do some more research on
this and report back tomorrow.

Thanks for the quick response,
Matt

On Thu, Mar 22, 2018, 4:10 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> Do you have a list of the tests which are concerned by this?
>
> Thanks,
>
> --Gunnar
>
>
> 2018-03-22 21:56 GMT+01:00 Matt Benson <mbenson at apache.org>:
>
>> Several TCK tests rely on this; however I have never seen anything in the
>> spec to dictate that this should be covered. Having said that, it is of
>> course extremely easy to implement this validation for Number, so I am
>> happy to test this as a missing item in the spec as opposed to a problem in
>> the TCK.
>>
>> Matt
>>
>> _______________________________________________
>> 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/20180322/e22321b2/attachment-0001.html 

From guillaume.smet at gmail.com  Fri Mar 23 04:28:38 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 23 Mar 2018 09:28:38 +0100
Subject: [bv-dev] Size validator for int
In-Reply-To: <CAE9L6G0xfooMYDkEeGd_ASTiM1r1Cqikkm8wZbAvXk_2t9UJSA@mail.gmail.com>
References: <CAE9L6G3SMOyd7Kdy4Ks9i+gNc+WkC8G7sj+cAO2LmSuqOu3Sqg@mail.gmail.com>
	<CADGJaX_94ifRz9EUD7=f9qzdqd68EB-uzTqnut7wiRDRwkyiCg@mail.gmail.com>
	<CAE9L6G0xfooMYDkEeGd_ASTiM1r1Cqikkm8wZbAvXk_2t9UJSA@mail.gmail.com>
Message-ID: <CALt0+o-8=uR+d+3zniN3OD4_ZyanHPVGuoWLAjBhyvjDBtAGvQ@mail.gmail.com>

Hi Matt,

On Thu, Mar 22, 2018 at 11:12 PM, Matt Benson <mbenson at apache.org> wrote:

> Yeah, this is weird. Elsewhere there is a test that specifically looks for
> there *not* being a Size validator for int. I will do some more research on
> this and report back tomorrow.
>

FWIW, we don't have one in HV so the TCK cannot expect the impl to have one.

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

From mbenson at apache.org  Fri Mar 23 13:46:03 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 23 Mar 2018 17:46:03 +0000
Subject: [bv-dev] TCK constraint composition problem WAS Size validator for
	int
Message-ID: <CAE9L6G3f2Z2uf96Cohr7kCMtSwKkHtu0fM_WmH1sALmHbJm==A@mail.gmail.com>

Okay, after digging a bit deeper I have come up with the following list of
affected tests:

org.hibernate.beanvalidation.tck.tests.metadata.PropertyDescriptorTest:

#testGetGroupConversionsForField

#testGetGroupConversionsForProperty

#testGetGroupConversionsReturnsEmptySet

#testIsCascaded

#testPropertyName



org.hibernate.beanvalidation.tck.tests.metadata.ConstraintDescriptorTest:

#testAnnotationAndMapParametersReflectParameterOverriding

#testComposingConstraints

#testComposingConstraintsPayload

#testGetGroups

#testGetGroupsOnInterface

#testGetGroupsWithImplicitGroup

#testGetMessageTemplate

#testGetValidationAppliesTo

#testGetValidationAppliesToFromComposingConstraint

#testGetValidationAppliesToReturnsNull

#testPayload

#testReportAsSingleViolation



org.hibernate.beanvalidation.tck.tests.metadata.BeanDescriptorTest:

#testGetConstraintsForUnConstrainedProperty

#testGetElementClassReturnsBeanClass

#testIsBeanConstrainedDueToConstraintOnInterface

#testIsBeanConstrainedDueToValidAnnotation



These tests have in common the fact that they use bean classes derived from
the org.hibernate.beanvalidation.tck.tests.metadata.Person interface, whose
#getAge() method declares @CustomConstraint, which inherits @Size as a
composing constraint via @CustomComposingConstraint.



Section 3.3 of the spec says:

The type upon which composed constraint is placed must be compatible with
all constraints (composing and composed).



I therefore conclude that the constraint applied to Person#getAge() is
incorrectly composed.



Thanks,

Matt



*CONFIDENTIALITY NOTICE: This e-mail, including any attachments, may
contain confidential, privileged and/or proprietary information which is
solely for the use of the intended recipient(s). Any review, use,
disclosure or retention by others is strictly prohibited. If you are not an
intended recipient, please contact the sender and delete this e-mail, any
attachments and all copies.*

Permanent General Assurance Corporation | Permanent General Assurance
Corporation of Ohio | The General Automobile Insurance Company, Inc. | Old
American County Mutual Fire Insurance Company | Home Office: 2636 Elm Hill
Pike, Nashville, TN 37214


On Fri, Mar 23, 2018, 3:35 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi Matt,
>
> On Thu, Mar 22, 2018 at 11:12 PM, Matt Benson <mbenson at apache.org> wrote:
>
>> Yeah, this is weird. Elsewhere there is a test that specifically looks
>> for there *not* being a Size validator for int. I will do some more
>> research on this and report back tomorrow.
>>
>
> FWIW, we don't have one in HV so the TCK cannot expect the impl to have
> one.
>
> --
> 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/20180323/cfe5a56a/attachment.html 

From guillaume.smet at gmail.com  Mon Mar 26 05:07:14 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 26 Mar 2018 11:07:14 +0200
Subject: [bv-dev] TCK constraint composition problem WAS Size validator
 for int
In-Reply-To: <CAE9L6G3f2Z2uf96Cohr7kCMtSwKkHtu0fM_WmH1sALmHbJm==A@mail.gmail.com>
References: <CAE9L6G3f2Z2uf96Cohr7kCMtSwKkHtu0fM_WmH1sALmHbJm==A@mail.gmail.com>
Message-ID: <CALt0+o_Uafd-sfsCaZO+mDevKqzadvkGYYAXWQcdoX97nxmNfA@mail.gmail.com>

Hi Matt,

On Fri, Mar 23, 2018 at 6:46 PM, Matt Benson <mbenson at apache.org> wrote:

> I therefore conclude that the constraint applied to Person#getAge() is
> incorrectly composed.
>
So do I:
https://hibernate.atlassian.net/browse/BVTCK-199
https://github.com/beanvalidation/beanvalidation-tck/pull/162

Cheers,

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

From mbenson at apache.org  Tue Mar 27 11:17:16 2018
From: mbenson at apache.org (Matt Benson)
Date: Tue, 27 Mar 2018 10:17:16 -0500
Subject: [bv-dev] TCK constraint composition problem WAS Size validator
 for int
In-Reply-To: <CALt0+o_Uafd-sfsCaZO+mDevKqzadvkGYYAXWQcdoX97nxmNfA@mail.gmail.com>
References: <CAE9L6G3f2Z2uf96Cohr7kCMtSwKkHtu0fM_WmH1sALmHbJm==A@mail.gmail.com>
	<CALt0+o_Uafd-sfsCaZO+mDevKqzadvkGYYAXWQcdoX97nxmNfA@mail.gmail.com>
Message-ID: <CAE9L6G2S539xxm1weUtDzvK2-o71-1Wo7o5KCY2JdhwaQXaV3g@mail.gmail.com>

Hi again,
Back to this issue, the commits to branch 2.0 of the TCK are fine.
However, as I continue working through our list of TCK failures, I
managed to trigger another problem with this same composed constraint.
It is explicitly applied to RETURN_VALUE of Person.getAge(), but the
@CustomComposingConstraint is applied to PARAMETERS, which by my
current cut of code runs afoul of the requirement in section 3.1.1.4
that it is illegal to specify PARAMETERS on an executable with no
parameters.

Matt

On Mon, Mar 26, 2018 at 4:07 AM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> Hi Matt,
>
> On Fri, Mar 23, 2018 at 6:46 PM, Matt Benson <mbenson at apache.org> wrote:
>>
>> I therefore conclude that the constraint applied to Person#getAge() is
>> incorrectly composed.
>
> So do I:
> https://hibernate.atlassian.net/browse/BVTCK-199
> https://github.com/beanvalidation/beanvalidation-tck/pull/162
>
> Cheers,
>
> --
> Guillaume
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From guillaume.smet at gmail.com  Tue Mar 27 16:46:23 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 27 Mar 2018 22:46:23 +0200
Subject: [bv-dev] TCK constraint composition problem WAS Size validator
 for int
In-Reply-To: <CAE9L6G2S539xxm1weUtDzvK2-o71-1Wo7o5KCY2JdhwaQXaV3g@mail.gmail.com>
References: <CAE9L6G3f2Z2uf96Cohr7kCMtSwKkHtu0fM_WmH1sALmHbJm==A@mail.gmail.com>
	<CALt0+o_Uafd-sfsCaZO+mDevKqzadvkGYYAXWQcdoX97nxmNfA@mail.gmail.com>
	<CAE9L6G2S539xxm1weUtDzvK2-o71-1Wo7o5KCY2JdhwaQXaV3g@mail.gmail.com>
Message-ID: <CALt0+o_GcyD5ATCagaWeZgQNo1_TKBmiZ9rTPYW0iGHJu4Gbyw@mail.gmail.com>

Hi Matt,

On Tue, Mar 27, 2018 at 5:17 PM, Matt Benson <mbenson at apache.org> wrote:

> Back to this issue, the commits to branch 2.0 of the TCK are fine.
> However, as I continue working through our list of TCK failures, I
> managed to trigger another problem with this same composed constraint.
> It is explicitly applied to RETURN_VALUE of Person.getAge(), but the
> @CustomComposingConstraint is applied to PARAMETERS, which by my
> current cut of code runs afoul of the requirement in section 3.1.1.4
> that it is illegal to specify PARAMETERS on an executable with no
> parameters.
>

Thanks for the PR, I just merged it.

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

From mbenson at apache.org  Wed Mar 28 11:30:41 2018
From: mbenson at apache.org (Matt Benson)
Date: Wed, 28 Mar 2018 10:30:41 -0500
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
Message-ID: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>

Hi all,
I'm having trouble recognizing what about TestEntity is supposed to
trigger the GroupDefinitionException in
#testInvalidDefinitionOfDefaultSequenceInEntity() (for convenience,
TestEntity is at [1]). The name of the test case suggests that the
problem would be on TestEntity's own @GroupSequence, which aside from
the order of the specified groups looks more or less like example 5.11
near [2]. This suggests that the test case is imperfectly named (the
name also seems misaligned with the accompanying @SpecAssertions) and
the focus intends to be on the Complete group of which validation is
attempted as the last activity of the test. Complete again looks
topographically identical to example 5.10 in the previous section of
the specification, which suggests that there is nothing inherently
wrong with it. I can appreciate that, when taking TestEntity's
redefinition of Default into account, Complete's sequence evaluates to
[ TimeConsumingChecks, TestEntity, TimeConsumingChecks]. This is
clearly repetitive/redundant, but is it really to be considered
cyclical? Is there any danger of infinite recursion and, if so, how?
Is there some other problem I have missed here?

Thanks,
Matt

[1] https://github.com/beanvalidation/beanvalidation-tck/blob/2.0/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/constraints/groups/groupsequence/TestEntity.java
[2] http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationprocess-groupsequence-redefiningdefaultgroup

From guillaume.smet at gmail.com  Thu Mar 29 05:18:16 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 29 Mar 2018 11:18:16 +0200
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
Message-ID: <CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>

Hi Matt,

I must admit that I don't see either what the problem should be.

The exception in HV is coming from:
https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/engine/groups/DefaultValidationOrder.java#L115
which didn't help me either to understand the issue as the method is quite
cryptic.

Gunnar, any idea?

-- 
Guillaume

On Wed, Mar 28, 2018 at 5:30 PM, Matt Benson <mbenson at apache.org> wrote:

> Hi all,
> I'm having trouble recognizing what about TestEntity is supposed to
> trigger the GroupDefinitionException in
> #testInvalidDefinitionOfDefaultSequenceInEntity() (for convenience,
> TestEntity is at [1]). The name of the test case suggests that the
> problem would be on TestEntity's own @GroupSequence, which aside from
> the order of the specified groups looks more or less like example 5.11
> near [2]. This suggests that the test case is imperfectly named (the
> name also seems misaligned with the accompanying @SpecAssertions) and
> the focus intends to be on the Complete group of which validation is
> attempted as the last activity of the test. Complete again looks
> topographically identical to example 5.10 in the previous section of
> the specification, which suggests that there is nothing inherently
> wrong with it. I can appreciate that, when taking TestEntity's
> redefinition of Default into account, Complete's sequence evaluates to
> [ TimeConsumingChecks, TestEntity, TimeConsumingChecks]. This is
> clearly repetitive/redundant, but is it really to be considered
> cyclical? Is there any danger of infinite recursion and, if so, how?
> Is there some other problem I have missed here?
>
> Thanks,
> Matt
>
> [1] https://github.com/beanvalidation/beanvalidation-
> tck/blob/2.0/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/
> constraints/groups/groupsequence/TestEntity.java
> [2] http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidatio
> nprocess-groupsequence-redefiningdefaultgroup
> _______________________________________________
> 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/20180329/bfe5f30d/attachment.html 

From mbenson at apache.org  Thu Mar 29 19:01:57 2018
From: mbenson at apache.org (Matt Benson)
Date: Thu, 29 Mar 2018 18:01:57 -0500
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec and TCK
Message-ID: <CAE9L6G3Vvqk7GszazTLbdz_gOe9JewUDUf0N9wPcfVYKO3KLyw@mail.gmail.com>

consider #validate_implicit_unwrapping_having_two_type_parameters_and_only_one_maximally_specific_value_extractor_marked_with_unwrap_by_default_is_ok():

What the spec says is:
...
If the constraint carries neither the Unwrapping.Unwrap nor the
Unwrapping.Skip payload:

If there is exactly one maximally-specific type-compliant value
extractor and this extractor is marked with @UnwrapByDefault, this
extractor is applied;

Otherwise, no value extractor is applied.
...

The test actually implements something more like:
If there is exactly one maximally-specific type-compliant value
extractor marked with @UnwrapByDefault, this extractor is applied,
etc.

The distinction is perhaps subtle, and I agree that the behavior
itself is reasonable; it just doesn't precisely agree with the current
wording, and I felt I should raise it as an issue.

Thanks,
Matt

From gunnar at hibernate.org  Fri Mar 30 07:55:52 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 30 Mar 2018 13:55:52 +0200
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
	<CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
Message-ID: <CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>

> I can appreciate that, when taking TestEntity's
redefinition of Default into account, Complete's sequence evaluates to
[ TimeConsumingChecks, TestEntity, TimeConsumingChecks]. This is
clearly repetitive/redundant, but is it really to be considered
cyclical?

I think this is key here. In 5.4.2, the spec says:

> Groups defining a sequence and groups composing a sequence must not be
involved in a cyclic dependency:
> * either directly or indirectly
> * either through cascaded sequence definitions or group inheritance
> If a group containing such a circularity is evaluated, a
GroupDefinitionException is raised.

I.e. you have a cycle between TimeConsumingChecks in the Complete group
sequence (once the re-defined default group sequence has been expanded).

In that light the method name is indeed a bit misleading, and I wonder
whether we have a simpler test in the TCK which just asserts that
@GroupSequence({ TimeConsumingChecks, TestEntity, TimeConsumingChecks })
triggers the exception. I didn't check the assignments of the assertion ids.

--Gunnar


2018-03-29 11:18 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> Hi Matt,
>
> I must admit that I don't see either what the problem should be.
>
> The exception in HV is coming from:
> https://github.com/hibernate/hibernate-validator/blob/
> master/engine/src/main/java/org/hibernate/validator/
> internal/engine/groups/DefaultValidationOrder.java#L115
> which didn't help me either to understand the issue as the method is quite
> cryptic.
>
> Gunnar, any idea?
>
> --
> Guillaume
>
> On Wed, Mar 28, 2018 at 5:30 PM, Matt Benson <mbenson at apache.org> wrote:
>
>> Hi all,
>> I'm having trouble recognizing what about TestEntity is supposed to
>> trigger the GroupDefinitionException in
>> #testInvalidDefinitionOfDefaultSequenceInEntity() (for convenience,
>> TestEntity is at [1]). The name of the test case suggests that the
>> problem would be on TestEntity's own @GroupSequence, which aside from
>> the order of the specified groups looks more or less like example 5.11
>> near [2]. This suggests that the test case is imperfectly named (the
>> name also seems misaligned with the accompanying @SpecAssertions) and
>> the focus intends to be on the Complete group of which validation is
>> attempted as the last activity of the test. Complete again looks
>> topographically identical to example 5.10 in the previous section of
>> the specification, which suggests that there is nothing inherently
>> wrong with it. I can appreciate that, when taking TestEntity's
>> redefinition of Default into account, Complete's sequence evaluates to
>> [ TimeConsumingChecks, TestEntity, TimeConsumingChecks]. This is
>> clearly repetitive/redundant, but is it really to be considered
>> cyclical? Is there any danger of infinite recursion and, if so, how?
>> Is there some other problem I have missed here?
>>
>> Thanks,
>> Matt
>>
>> [1] https://github.com/beanvalidation/beanvalidation-tck/blob/2.
>> 0/tests/src/main/java/org/hibernate/beanvalidation/tck/
>> tests/constraints/groups/groupsequence/TestEntity.java
>> [2] http://beanvalidation.org/2.0/spec/#constraintdeclarationval
>> idationprocess-groupsequence-redefiningdefaultgroup
>> _______________________________________________
>> 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/20180330/fd038cb3/attachment-0001.html 

From guillaume.smet at gmail.com  Fri Mar 30 08:46:02 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 30 Mar 2018 14:46:02 +0200
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec
	and TCK
In-Reply-To: <CAE9L6G3Vvqk7GszazTLbdz_gOe9JewUDUf0N9wPcfVYKO3KLyw@mail.gmail.com>
References: <CAE9L6G3Vvqk7GszazTLbdz_gOe9JewUDUf0N9wPcfVYKO3KLyw@mail.gmail.com>
Message-ID: <CALt0+o-jpzZfg3m0R4gdpaCiTyb6mKVPrc1d2OVQG4HNvGNPPw@mail.gmail.com>

Hi Matt,

On Fri, Mar 30, 2018 at 1:01 AM, Matt Benson <mbenson at apache.org> wrote:

> The distinction is perhaps subtle, and I agree that the behavior
> itself is reasonable; it just doesn't precisely agree with the current
> wording, and I felt I should raise it as an issue.
>

I remember us having discussions about this and I think the TCK tests are
the outcome of this discussion.

It looks like we haven't updated the spec though.

Not sure what to do about this one. The TCK tests make more sense than the
spec and IIRC that's what we decided to do.

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

From guillaume.smet at gmail.com  Fri Mar 30 08:47:30 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 30 Mar 2018 14:47:30 +0200
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
	<CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
	<CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>
Message-ID: <CALt0+o9oeJJi=O1yXYTUy7d+bfXFo-r1xcFMSh2huTML0_X8HQ@mail.gmail.com>

On Fri, Mar 30, 2018 at 1:55 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> I.e. you have a cycle between TimeConsumingChecks in the Complete group
> sequence (once the re-defined default group sequence has been expanded).
>
> In that light the method name is indeed a bit misleading, and I wonder
> whether we have a simpler test in the TCK which just asserts that
> @GroupSequence({ TimeConsumingChecks, TestEntity, TimeConsumingChecks })
> triggers the exception. I didn't check the assignments of the assertion ids.
>

I thinks that Matt and I aren't that convinced that it is a cyclic
dependency. Sure one of the groups appears 2 times but it's not really
cyclic.

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

From gunnar at hibernate.org  Fri Mar 30 08:57:39 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 30 Mar 2018 14:57:39 +0200
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <CALt0+o9oeJJi=O1yXYTUy7d+bfXFo-r1xcFMSh2huTML0_X8HQ@mail.gmail.com>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
	<CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
	<CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>
	<CALt0+o9oeJJi=O1yXYTUy7d+bfXFo-r1xcFMSh2huTML0_X8HQ@mail.gmail.com>
Message-ID: <CADGJaX8QvgqTkxqmLUPUX3dszQgqDtRZr4gNTJU72mGTRsXtMg@mail.gmail.com>

If not that, what else would you consider as a cycle in the context of
group sequence definitions then?

This sequence definition here says: "validate TimeConsumingChecks *before*
TestEntity" and "validate TimeConsumingChecks *after* TestEntity", aborting
after the first group found with violated constraints. There's no way to
implement this.

2018-03-30 14:47 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> On Fri, Mar 30, 2018 at 1:55 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> I.e. you have a cycle between TimeConsumingChecks in the Complete group
>> sequence (once the re-defined default group sequence has been expanded).
>>
>> In that light the method name is indeed a bit misleading, and I wonder
>> whether we have a simpler test in the TCK which just asserts that
>> @GroupSequence({ TimeConsumingChecks, TestEntity, TimeConsumingChecks })
>> triggers the exception. I didn't check the assignments of the assertion ids.
>>
>
> I thinks that Matt and I aren't that convinced that it is a cyclic
> dependency. Sure one of the groups appears 2 times but it's not really
> cyclic.
>
> --
> 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/20180330/0fcf675e/attachment.html 

From mbenson at apache.org  Fri Mar 30 09:00:52 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 30 Mar 2018 13:00:52 +0000
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec
	and TCK
In-Reply-To: <CALt0+o-jpzZfg3m0R4gdpaCiTyb6mKVPrc1d2OVQG4HNvGNPPw@mail.gmail.com>
References: <CAE9L6G3Vvqk7GszazTLbdz_gOe9JewUDUf0N9wPcfVYKO3KLyw@mail.gmail.com>
	<CALt0+o-jpzZfg3m0R4gdpaCiTyb6mKVPrc1d2OVQG4HNvGNPPw@mail.gmail.com>
Message-ID: <CAE9L6G0cGkRac=-xuAp2ubjpFjZzkG3jN5g1DpAEE3FpkyJV6A@mail.gmail.com>

Can we just make the change in the source of the spec so that it will have
been handled should we do a 2.1 version? Failing that, could this
particular test be somehow marked as optional for an implementation to
pass? I've made the changes to permit it in the Apache implementation in
any case.

Matt

On Fri, Mar 30, 2018, 7:46 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi Matt,
>
> On Fri, Mar 30, 2018 at 1:01 AM, Matt Benson <mbenson at apache.org> wrote:
>
>> The distinction is perhaps subtle, and I agree that the behavior
>> itself is reasonable; it just doesn't precisely agree with the current
>> wording, and I felt I should raise it as an issue.
>>
>
> I remember us having discussions about this and I think the TCK tests are
> the outcome of this discussion.
>
> It looks like we haven't updated the spec though.
>
> Not sure what to do about this one. The TCK tests make more sense than the
> spec and IIRC that's what we decided to do.
>
> --
> 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/20180330/738c5780/attachment.html 

From guillaume.smet at gmail.com  Fri Mar 30 09:34:18 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 30 Mar 2018 15:34:18 +0200
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <CADGJaX8QvgqTkxqmLUPUX3dszQgqDtRZr4gNTJU72mGTRsXtMg@mail.gmail.com>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
	<CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
	<CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>
	<CALt0+o9oeJJi=O1yXYTUy7d+bfXFo-r1xcFMSh2huTML0_X8HQ@mail.gmail.com>
	<CADGJaX8QvgqTkxqmLUPUX3dszQgqDtRZr4gNTJU72mGTRsXtMg@mail.gmail.com>
Message-ID: <CALt0+o96EWYAPpqXnNvb_QPN5VkgZ-eakrPECSRVROYaqak-1w@mail.gmail.com>

On Fri, Mar 30, 2018 at 2:57 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> If not that, what else would you consider as a cycle in the context of
> group sequence definitions then?
>
> This sequence definition here says: "validate TimeConsumingChecks *before*
> TestEntity" and "validate TimeConsumingChecks *after* TestEntity",
> aborting after the first group found with violated constraints. There's no
> way to implement this.
>

Not saying it makes sense but I could imagine validating
TimeConsumingChecks then TestEntity then TimeConsumingChecks again.

If we consider this a cyclic dependency, then the test is indeed valid. The
name is not very descriptive but it's not wrong either.

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180330/4b4f2c01/attachment-0001.html 

From mbenson at apache.org  Fri Mar 30 09:48:43 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 30 Mar 2018 13:48:43 +0000
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <CALt0+o96EWYAPpqXnNvb_QPN5VkgZ-eakrPECSRVROYaqak-1w@mail.gmail.com>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
	<CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
	<CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>
	<CALt0+o9oeJJi=O1yXYTUy7d+bfXFo-r1xcFMSh2huTML0_X8HQ@mail.gmail.com>
	<CADGJaX8QvgqTkxqmLUPUX3dszQgqDtRZr4gNTJU72mGTRsXtMg@mail.gmail.com>
	<CALt0+o96EWYAPpqXnNvb_QPN5VkgZ-eakrPECSRVROYaqak-1w@mail.gmail.com>
Message-ID: <CAE9L6G1tg76BWq5hrhcVQ-rigrL9NE2uW+tnBh4rM-bXcTnftg@mail.gmail.com>

I think the issue is that Guillaume and I are viewing the group sequence as
a simple, ordered set of instructions, whereas you, Gunnar, are viewing it
more as a dependency graph. I will confess that I am having difficulty
rising to your challenge of providing an example that would be indisputably
cyclical without having sat down at a computer or with pen and paper to
postulate one. In the meantime I wonder if there is anything in the spec to
encourage this "dependency graph" interpretation of what a group sequence
is. Having said that, it is probably true that a user who had set up such a
situation as this had done so unintentionally. OTOH, the second attempt at
validating the time consuming checks would be a noop in any case.

Matt

On Fri, Mar 30, 2018, 8:36 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Fri, Mar 30, 2018 at 2:57 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> If not that, what else would you consider as a cycle in the context of
>> group sequence definitions then?
>>
>> This sequence definition here says: "validate TimeConsumingChecks *before
>> * TestEntity" and "validate TimeConsumingChecks *after* TestEntity",
>> aborting after the first group found with violated constraints. There's no
>> way to implement this.
>>
>
> Not saying it makes sense but I could imagine validating
> TimeConsumingChecks then TestEntity then TimeConsumingChecks again.
>
> If we consider this a cyclic dependency, then the test is indeed valid.
> The name is not very descriptive but it's not wrong either.
>
> --
> 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/20180330/cbd73d3d/attachment.html 

From guillaume.smet at gmail.com  Fri Mar 30 10:05:37 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 30 Mar 2018 16:05:37 +0200
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <CAE9L6G1tg76BWq5hrhcVQ-rigrL9NE2uW+tnBh4rM-bXcTnftg@mail.gmail.com>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
	<CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
	<CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>
	<CALt0+o9oeJJi=O1yXYTUy7d+bfXFo-r1xcFMSh2huTML0_X8HQ@mail.gmail.com>
	<CADGJaX8QvgqTkxqmLUPUX3dszQgqDtRZr4gNTJU72mGTRsXtMg@mail.gmail.com>
	<CALt0+o96EWYAPpqXnNvb_QPN5VkgZ-eakrPECSRVROYaqak-1w@mail.gmail.com>
	<CAE9L6G1tg76BWq5hrhcVQ-rigrL9NE2uW+tnBh4rM-bXcTnftg@mail.gmail.com>
Message-ID: <CALt0+o8X9usKzr88GOcRqnY54jBoPk8Jyd4TUqkaiMQCViZPVA@mail.gmail.com>

On Fri, Mar 30, 2018 at 3:48 PM, Matt Benson <mbenson at apache.org> wrote:

> I think the issue is that Guillaume and I are viewing the group sequence
> as a simple, ordered set of instructions, whereas you, Gunnar, are viewing
> it more as a dependency graph. I will confess that I am having difficulty
> rising to your challenge of providing an example that would be indisputably
> cyclical without having sat down at a computer or with pen and paper to
> postulate one. In the meantime I wonder if there is anything in the spec to
> encourage this "dependency graph" interpretation of what a group sequence
> is. Having said that, it is probably true that a user who had set up such a
> situation as this had done so unintentionally. OTOH, the second attempt at
> validating the time consuming checks would be a noop in any case.
>

Yeah, for me, a cyclical dependency was more when you have a loop in the
group hierarchy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180330/1831badd/attachment.html 

From guillaume.smet at gmail.com  Fri Mar 30 10:06:33 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 30 Mar 2018 16:06:33 +0200
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec
	and TCK
In-Reply-To: <CAE9L6G0cGkRac=-xuAp2ubjpFjZzkG3jN5g1DpAEE3FpkyJV6A@mail.gmail.com>
References: <CAE9L6G3Vvqk7GszazTLbdz_gOe9JewUDUf0N9wPcfVYKO3KLyw@mail.gmail.com>
	<CALt0+o-jpzZfg3m0R4gdpaCiTyb6mKVPrc1d2OVQG4HNvGNPPw@mail.gmail.com>
	<CAE9L6G0cGkRac=-xuAp2ubjpFjZzkG3jN5g1DpAEE3FpkyJV6A@mail.gmail.com>
Message-ID: <CALt0+o-Gcz32H1FcKfHJQ4XVZg9E47b0BgjPtsa9r-rHXtMVcQ@mail.gmail.com>

On Fri, Mar 30, 2018 at 3:00 PM, Matt Benson <mbenson at apache.org> wrote:

> Can we just make the change in the source of the spec so that it will have
> been handled should we do a 2.1 version? Failing that, could this
> particular test be somehow marked as optional for an implementation to
> pass? I've made the changes to permit it in the Apache implementation in
> any case.
>

Changing the spec for 2.1 would be my preference.

Let's wait for Gunnar insights. He's the master of the spec.

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

From mbenson at apache.org  Fri Mar 30 11:17:17 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 30 Mar 2018 10:17:17 -0500
Subject: [bv-dev] Validator#validateValue() with incompatible Object
	specified
Message-ID: <CAE9L6G2Q3QMQUDsM0DiwJLn5L46XAbs8yb=icv+Kf_xUtOuBzA@mail.gmail.com>

Hi, this comes from TCK
ValidateValueTest#testValidIsNotHonoredValidateValue() . The test
asserts that no constraint violations (and no exceptions) will be
generated when specifying an Order as a proposed value for a property
that includes a Set of Orders. The name of the test suggests to me,
however, that the Validator is expected to transparently treat the
Order as a single-element Set and simply show that validation of that
set is not cascaded. Is this the case, or is the test actually showing
that any incompatible value will be treated as raising no violations
(and is therefore imperfectly named)? In either case, where does the
specification dictate this behavior? Apache BVal has always raised an
IllegalArgumentException if the specified value is not compatible, but
its justification for having done so appears to be an artifact of an
incorrect interpretation of the Javadoc of #validateValue(): "not a
valid object property" was mistakenly applied to the "value" parameter
instead of to the "propertyName" parameter as a careful reading
reveals (IMO) is proper. But this exposes what seems to be an omission
in the spec: what *is* the proper behavior when validation of an
incompatible value is requested? And let's not forget the unclear
nature of the test in question: is "order" a compatible value by
virtue of being checked against a Set of its type (and, if so, why?),
or is "order" an incompatible value that the Validator quietly
abstains from checking at all?

Thanks,
Matt

From mbenson at apache.org  Fri Mar 30 11:33:56 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 30 Mar 2018 10:33:56 -0500
Subject: [bv-dev] Validator#validateValue() with incompatible Object
	specified
In-Reply-To: <CAE9L6G2Q3QMQUDsM0DiwJLn5L46XAbs8yb=icv+Kf_xUtOuBzA@mail.gmail.com>
References: <CAE9L6G2Q3QMQUDsM0DiwJLn5L46XAbs8yb=icv+Kf_xUtOuBzA@mail.gmail.com>
Message-ID: <CAE9L6G1ViY7-LKsxtgc=QkHOhkLvtACLXTY97WU1iD+6tDNEvA@mail.gmail.com>

I would add that other recent discussions have borne out my
interpretation of the ExecutableValidator javadoc in saying that
incompatible parameter/return values should raise
IllegalArgumentExceptions. I would see this as a precedent in the case
of #validateValue().

Matt

On Fri, Mar 30, 2018 at 10:17 AM, Matt Benson <mbenson at apache.org> wrote:
> Hi, this comes from TCK
> ValidateValueTest#testValidIsNotHonoredValidateValue() . The test
> asserts that no constraint violations (and no exceptions) will be
> generated when specifying an Order as a proposed value for a property
> that includes a Set of Orders. The name of the test suggests to me,
> however, that the Validator is expected to transparently treat the
> Order as a single-element Set and simply show that validation of that
> set is not cascaded. Is this the case, or is the test actually showing
> that any incompatible value will be treated as raising no violations
> (and is therefore imperfectly named)? In either case, where does the
> specification dictate this behavior? Apache BVal has always raised an
> IllegalArgumentException if the specified value is not compatible, but
> its justification for having done so appears to be an artifact of an
> incorrect interpretation of the Javadoc of #validateValue(): "not a
> valid object property" was mistakenly applied to the "value" parameter
> instead of to the "propertyName" parameter as a careful reading
> reveals (IMO) is proper. But this exposes what seems to be an omission
> in the spec: what *is* the proper behavior when validation of an
> incompatible value is requested? And let's not forget the unclear
> nature of the test in question: is "order" a compatible value by
> virtue of being checked against a Set of its type (and, if so, why?),
> or is "order" an incompatible value that the Validator quietly
> abstains from checking at all?
>
> Thanks,
> Matt

From mbenson at apache.org  Fri Mar 30 11:51:23 2018
From: mbenson at apache.org (Matt Benson)
Date: Fri, 30 Mar 2018 10:51:23 -0500
Subject: [bv-dev] Apparent TCK misuse of ValidationTarget.PARAMETERS
Message-ID: <CAE9L6G3DCbTp0Y0i4GSF1QNL5pTTxhA67g-T3LSytTd-XsDXag@mail.gmail.com>

Consider test ValidationInterceptorPriorityTest#testValidationInterceptorHasPriority4800():

The example validates that the parameter to
CalendarService#createEvent(String) satisfies @CustomConstraint.
However, the sole validator declared for @CustomConstraint,
CustomConstraintValidator, is marked as supporting
ValidationTarget.PARAMETERS . In turn, the spec and Javadoc clearly
indicate that ValidationTarget.PARAMETERS indicates cross-parameter
validation. I think this one would be satisfied either by simply
removing @SupportedValidationTarget from the CV impl, or by adding
ANNOTATED_ELEMENT.

Thanks,
Matt

From emmanuel at hibernate.org  Fri Mar 30 17:14:30 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 30 Mar 2018 23:14:30 +0200
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <CAE9L6G1tg76BWq5hrhcVQ-rigrL9NE2uW+tnBh4rM-bXcTnftg@mail.gmail.com>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
	<CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
	<CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>
	<CALt0+o9oeJJi=O1yXYTUy7d+bfXFo-r1xcFMSh2huTML0_X8HQ@mail.gmail.com>
	<CADGJaX8QvgqTkxqmLUPUX3dszQgqDtRZr4gNTJU72mGTRsXtMg@mail.gmail.com>
	<CALt0+o96EWYAPpqXnNvb_QPN5VkgZ-eakrPECSRVROYaqak-1w@mail.gmail.com>
	<CAE9L6G1tg76BWq5hrhcVQ-rigrL9NE2uW+tnBh4rM-bXcTnftg@mail.gmail.com>
Message-ID: <BAD46721-8701-4C5B-BFEC-1F4628748FB7@hibernate.org>

Gunnar is expressing the intent correctly as far as memory serves. I did want a *non ambiguous* partiall order behavior in sequences. The example makes it ambiguous. 

But groups and group sequences are probably in the top 3 of the most complicated piece of specification in the whole Java EE ecosystem. Not proud of it but it works as expected for all real life code of which thus test is not a representative :)

Emmanuel

> On 30 Mar 2018, at 15:48, Matt Benson <mbenson at apache.org> wrote:
> 
> I think the issue is that Guillaume and I are viewing the group sequence as a simple, ordered set of instructions, whereas you, Gunnar, are viewing it more as a dependency graph. I will confess that I am having difficulty rising to your challenge of providing an example that would be indisputably cyclical without having sat down at a computer or with pen and paper to postulate one. In the meantime I wonder if there is anything in the spec to encourage this "dependency graph" interpretation of what a group sequence is. Having said that, it is probably true that a user who had set up such a situation as this had done so unintentionally. OTOH, the second attempt at validating the time consuming checks would be a noop in any case.
> 
> Matt
> 
>> On Fri, Mar 30, 2018, 8:36 AM Guillaume Smet <guillaume.smet at gmail.com> wrote:
>>> On Fri, Mar 30, 2018 at 2:57 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> If not that, what else would you consider as a cycle in the context of group sequence definitions then?
>>> 
>>> This sequence definition here says: "validate TimeConsumingChecks *before* TestEntity" and "validate TimeConsumingChecks *after* TestEntity", aborting after the first group found with violated constraints. There's no way to implement this.
>> 
>> Not saying it makes sense but I could imagine validating TimeConsumingChecks then TestEntity then TimeConsumingChecks again.
>> 
>> If we consider this a cyclic dependency, then the test is indeed valid. The name is not very descriptive but it's not wrong either.
>> 
>> -- 
>> Guillaume
>> _______________________________________________
>> 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/20180330/2c07ef16/attachment.html 

From gunnar at hibernate.org  Sat Mar 31 05:51:31 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 31 Mar 2018 11:51:31 +0200
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec
	and TCK
In-Reply-To: <CALt0+o-Gcz32H1FcKfHJQ4XVZg9E47b0BgjPtsa9r-rHXtMVcQ@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>
Message-ID: <CADGJaX95SY0pkhtahicge5zTabq=f8ZDrjpnMTCdhNMYejz0Qg@mail.gmail.com>

That's an interesting one; it was originally worded exactly like Matt
suggests, but then we changed into the current version:
https://hibernate.atlassian.net/browse/BVAL-678.

I'm sympathetic to the current behaviour of that TCK test and to adjusting
the spec wording accordingly. Only you, Guillaume, didn't seem to like that
alternative as per our discussion on June 26th, in the Hibernate Validator
chat room. Perhaps you remember what made you dislike it back then?


2018-03-30 16:06 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> On Fri, Mar 30, 2018 at 3:00 PM, Matt Benson <mbenson at apache.org> wrote:
>
>> Can we just make the change in the source of the spec so that it will
>> have been handled should we do a 2.1 version? Failing that, could this
>> particular test be somehow marked as optional for an implementation to
>> pass? I've made the changes to permit it in the Apache implementation in
>> any case.
>>
>
> Changing the spec for 2.1 would be my preference.
>
> Let's wait for Gunnar insights. He's the master of the spec.
>
> --
> 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/20180331/246023bd/attachment.html 

From guillaume.smet at gmail.com  Sat Mar 31 07:42:33 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Sat, 31 Mar 2018 13:42:33 +0200
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec
	and TCK
In-Reply-To: <CADGJaX95SY0pkhtahicge5zTabq=f8ZDrjpnMTCdhNMYejz0Qg@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>
Message-ID: <CALt0+o_UPGOnFKYDL=ovhNOsgjTr5RJqDseqam4DWymEdD-6+Q@mail.gmail.com>

On Sat, Mar 31, 2018 at 11:51 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> That's an interesting one; it was originally worded exactly like Matt
> suggests, but then we changed into the current version:
> https://hibernate.atlassian.net/browse/BVAL-678.
>
> I'm sympathetic to the current behaviour of that TCK test and to adjusting
> the spec wording accordingly. Only you, Guillaume, didn't seem to like that
> alternative as per our discussion on June 26th, in the Hibernate Validator
> chat room. Perhaps you remember what made you dislike it back then?
>

Ah, yes, I remember now.

The paragraph is:

   - If the constraint carries neither the Unwrapping.Unwrap nor the
   Unwrapping.Skip payload:
   - If there is exactly one maximally-specific type-compliant value
      extractor and this extractor is marked with @UnwrapByDefault, this
      extractor is applied;
      - Otherwise, no value extractor is applied.

The initial wording "exactly one maximally-specific type-compliant value
extractor marked with @UnwrapByDefault" was not accurate because it was not
clear if we should determine the "maximally-specific type-compliant value
extractor" first and then check if it is @UnwrapByDefault. This is
important because, for a given type parameter, we want to get the maximally
specific value extractor first and then we want to check if it is marked
with @UnwrapByDefault. We don't want to get the maximally specific (value
extractor marked with @UnwrapByDefault).

We also miss a mention of the case when there are 2 maximally-specific
type-compliant value extractors marked with @UnwrapByDefault.

I think a wording more in line with our intentions would be:

   - We determine the maximally-specific type-compliant value extractors.
   - If there are no matching value extractors or none is marked with
      @UnwrapByDefault, no value extractor is applied.
      - If exactly one is marked with @UnwrapByDefault, this very extractor
      is applied.
      - If more than one are marked with @UnwrapByDefault, a
      ConstraintDeclarationException is raised.

I would lean towards implementing it this way in the implementations and
fix it for BV 2.1.

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

From gunnar at hibernate.org  Sat Mar 31 08:19:35 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 31 Mar 2018 14:19:35 +0200
Subject: [bv-dev] ValueExtractionUnwrappingTest: quibble between spec
	and TCK
In-Reply-To: <CALt0+o_UPGOnFKYDL=ovhNOsgjTr5RJqDseqam4DWymEdD-6+Q@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>
Message-ID: <CADGJaX9-=fMD8GeW7-OUsj9nvHruuPzn6iXvG577+41cS6CJ-A@mail.gmail.com>

2018-03-31 13:42 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> On Sat, Mar 31, 2018 at 11:51 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> That's an interesting one; it was originally worded exactly like Matt
>> suggests, but then we changed into the current version:
>> https://hibernate.atlassian.net/browse/BVAL-678.
>>
>> I'm sympathetic to the current behaviour of that TCK test and to
>> adjusting the spec wording accordingly. Only you, Guillaume, didn't seem to
>> like that alternative as per our discussion on June 26th, in the Hibernate
>> Validator chat room. Perhaps you remember what made you dislike it back
>> then?
>>
>
> Ah, yes, I remember now.
>
> The paragraph is:
>
>    - If the constraint carries neither the Unwrapping.Unwrap nor the
>    Unwrapping.Skip payload:
>    - If there is exactly one maximally-specific type-compliant value
>       extractor and this extractor is marked with @UnwrapByDefault, this
>       extractor is applied;
>       - Otherwise, no value extractor is applied.
>
> The initial wording "exactly one maximally-specific type-compliant value
> extractor marked with @UnwrapByDefault" was not accurate because it was not
> clear if we should determine the "maximally-specific type-compliant value
> extractor" first and then check if it is @UnwrapByDefault. This is
> important because, for a given type parameter, we want to get the maximally
> specific value extractor first and then we want to check if it is marked
> with @UnwrapByDefault. We don't want to get the maximally specific (value
> extractor marked with @UnwrapByDefault).
>
> We also miss a mention of the case when there are 2 maximally-specific
> type-compliant value extractors marked with @UnwrapByDefault.
>
> I think a wording more in line with our intentions would be:
>
>    - We determine the maximally-specific type-compliant value extractors.
>    - If there are no matching value extractors or none is marked with
>       @UnwrapByDefault, no value extractor is applied.
>       - If exactly one is marked with @UnwrapByDefault, this very
>       extractor is applied.
>
> Ok so far.

>
>    - 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.

The original wording could be interpreted in the way above, but +1 for
making it more exhaustive. Can you log a BVAL issue for 2.1?


> I would lean towards implementing it this way in the implementations and
> fix it for BV 2.1.
>

+1 apart from the case where there are multiple maximally-specific
type-compliant value extractors marked with @ UBD as discussed above.

>
> --
> 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/20180331/f50e0411/attachment-0001.html 

From gunnar at hibernate.org  Sat Mar 31 09:02:27 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 31 Mar 2018 15:02:27 +0200
Subject: [bv-dev] Validator#validateValue() with incompatible Object
	specified
In-Reply-To: <CAE9L6G1ViY7-LKsxtgc=QkHOhkLvtACLXTY97WU1iD+6tDNEvA@mail.gmail.com>
References: <CAE9L6G2Q3QMQUDsM0DiwJLn5L46XAbs8yb=icv+Kf_xUtOuBzA@mail.gmail.com>
	<CAE9L6G1ViY7-LKsxtgc=QkHOhkLvtACLXTY97WU1iD+6tDNEvA@mail.gmail.com>
Message-ID: <CADGJaX8J-=LiyRDPHXtGOPdMpjBV6TADF+54AnEqyf9F8_yVDw@mail.gmail.com>

Hey Matt,

I think you're giving too much bonus to the original authors of that test
method and their well-meaning intentions ;) IMO the test is simply
incorrect, for sure the intention was not that a single Order should
implicitly be handled as a single-element Set<Order>.

The reason it doesn't fail with the RI is simply the fact that the RI is
actually doing what the test seeks to ensure: @Valid isn't applied by
validateValue(), i.e. the algorithm never gets to the point where it'd make
use of the given value to recursively validate the constraints of the
"orders" property. Were validateValue() be invoked for another property
with a local constraint, a ClassCastException would occur when trying to
feed the non-matching value to the ConstraintValidator.

Can you open a BVTCK issue for fixing this test? A Set<Order> containing
the Order object should be passed to validateValue().

Regarding the expected behaviour, indeed the spec doesn't mandate something
specifically. I don't think it's a big problem, though, because the
non-matching value will cause an exception in one or another way anyways.
Theoretically we could mandate a specific IllegalArgumentException in that
case, but that'd require an instanceof check up front, and I don't think I
wanted to impose this to implementations. I'd rather leave it as is; of
course an implementation is free to do such check, as Apache Bval was doing
it.

As far as ExecutableValidator is concerned, there it says to raise an
exception if "parameters don't match with each other". This leaves some
leeway on the exact checks to implement and also here I'd prefer to keep it
that way, instead of enforcing potentially costly checks at the spec level.

--Gunnar

2018-03-30 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:

> I would add that other recent discussions have borne out my
> interpretation of the ExecutableValidator javadoc in saying that
> incompatible parameter/return values should raise
> IllegalArgumentExceptions. I would see this as a precedent in the case
> of #validateValue().
>
> Matt
>
> On Fri, Mar 30, 2018 at 10:17 AM, Matt Benson <mbenson at apache.org> wrote:
> > Hi, this comes from TCK
> > ValidateValueTest#testValidIsNotHonoredValidateValue() . The test
> > asserts that no constraint violations (and no exceptions) will be
> > generated when specifying an Order as a proposed value for a property
> > that includes a Set of Orders. The name of the test suggests to me,
> > however, that the Validator is expected to transparently treat the
> > Order as a single-element Set and simply show that validation of that
> > set is not cascaded. Is this the case, or is the test actually showing
> > that any incompatible value will be treated as raising no violations
> > (and is therefore imperfectly named)? In either case, where does the
> > specification dictate this behavior? Apache BVal has always raised an
> > IllegalArgumentException if the specified value is not compatible, but
> > its justification for having done so appears to be an artifact of an
> > incorrect interpretation of the Javadoc of #validateValue(): "not a
> > valid object property" was mistakenly applied to the "value" parameter
> > instead of to the "propertyName" parameter as a careful reading
> > reveals (IMO) is proper. But this exposes what seems to be an omission
> > in the spec: what *is* the proper behavior when validation of an
> > incompatible value is requested? And let's not forget the unclear
> > nature of the test in question: is "order" a compatible value by
> > virtue of being checked against a Set of its type (and, if so, why?),
> > or is "order" an incompatible value that the Validator quietly
> > abstains from checking at all?
> >
> > Thanks,
> > 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/20180331/79ac7e74/attachment.html 

From mbenson at apache.org  Sat Mar 31 12:07:49 2018
From: mbenson at apache.org (Matt Benson)
Date: Sat, 31 Mar 2018 11:07:49 -0500
Subject: [bv-dev] Questions on TCK SequenceResolutionTest
In-Reply-To: <BAD46721-8701-4C5B-BFEC-1F4628748FB7@hibernate.org>
References: <CAE9L6G3K3JpTy__oPzVevYTJ7FpH9Y0SCMHBUkRPxxWrDT4QBw@mail.gmail.com>
	<CALt0+o-B2HfjFetcPkytAi__tLEo9HVbAQs-j_Bej7cHkAxiTA@mail.gmail.com>
	<CADGJaX8GKuAaWnaYmnTWTiuyA0bc4zW0E-6qxywU64fg9-7FxQ@mail.gmail.com>
	<CALt0+o9oeJJi=O1yXYTUy7d+bfXFo-r1xcFMSh2huTML0_X8HQ@mail.gmail.com>
	<CADGJaX8QvgqTkxqmLUPUX3dszQgqDtRZr4gNTJU72mGTRsXtMg@mail.gmail.com>
	<CALt0+o96EWYAPpqXnNvb_QPN5VkgZ-eakrPECSRVROYaqak-1w@mail.gmail.com>
	<CAE9L6G1tg76BWq5hrhcVQ-rigrL9NE2uW+tnBh4rM-bXcTnftg@mail.gmail.com>
	<BAD46721-8701-4C5B-BFEC-1F4628748FB7@hibernate.org>
Message-ID: <CAE9L6G2JvqhdvibopyOR4OboTPLq2KY4eCogjZOsGnHG1r78PQ@mail.gmail.com>

I will adjust my mental model to the "dependency graph" interpretation
and the Apache BVal code accordingly. Thanks all!

On Fri, Mar 30, 2018 at 4:14 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> Gunnar is expressing the intent correctly as far as memory serves. I did
> want a *non ambiguous* partiall order behavior in sequences. The example
> makes it ambiguous.
>
> But groups and group sequences are probably in the top 3 of the most
> complicated piece of specification in the whole Java EE ecosystem. Not proud
> of it but it works as expected for all real life code of which thus test is
> not a representative :)
>
> Emmanuel
>
> On 30 Mar 2018, at 15:48, Matt Benson <mbenson at apache.org> wrote:
>
> I think the issue is that Guillaume and I are viewing the group sequence as
> a simple, ordered set of instructions, whereas you, Gunnar, are viewing it
> more as a dependency graph. I will confess that I am having difficulty
> rising to your challenge of providing an example that would be indisputably
> cyclical without having sat down at a computer or with pen and paper to
> postulate one. In the meantime I wonder if there is anything in the spec to
> encourage this "dependency graph" interpretation of what a group sequence
> is. Having said that, it is probably true that a user who had set up such a
> situation as this had done so unintentionally. OTOH, the second attempt at
> validating the time consuming checks would be a noop in any case.
>
> Matt
>
> On Fri, Mar 30, 2018, 8:36 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>>
>> On Fri, Mar 30, 2018 at 2:57 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> If not that, what else would you consider as a cycle in the context of
>>> group sequence definitions then?
>>>
>>> This sequence definition here says: "validate TimeConsumingChecks
>>> *before* TestEntity" and "validate TimeConsumingChecks *after* TestEntity",
>>> aborting after the first group found with violated constraints. There's no
>>> way to implement this.
>>
>>
>> Not saying it makes sense but I could imagine validating
>> TimeConsumingChecks then TestEntity then TimeConsumingChecks again.
>>
>> If we consider this a cyclic dependency, then the test is indeed valid.
>> The name is not very descriptive but it's not wrong either.
>>
>> --
>> Guillaume
>> _______________________________________________
>> 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