3:55 p.m.
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
4:17 a.m.
Hi Matt,
On Wed, Mar 21, 2018 at 9:55 PM, Matt Benson <mbenson(a)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
5:41 a.m.
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(a)gmail.com>:
Hi Matt,
On Wed, Mar 21, 2018 at 9:55 PM, Matt Benson <mbenson(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
8:13 a.m.
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(a)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(a)gmail.com>:
> Hi Matt,
>
> On Wed, Mar 21, 2018 at 9:55 PM, Matt Benson <mbenson(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:32 a.m.
On Thu, Mar 22, 2018 at 11:41 AM, Gunnar Morling <gunnar(a)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
2472
days inactive
2473
days old
beanvalidation-dev@lists.jboss.org
4 comments
3 participants
participants (3)
-
Guillaume Smet -
Gunnar Morling -
Matt Benson