bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: Urgent problem with PathImpl
Date Wed, 29 Sep 2010 01:14:31 GMT

On Sep 28, 2010, at 4:52 PM, Carlos Vara wrote:

> Hi again Matt,
> this is the issue in which I added the changes to pass the tests:
> From its message:
> "Call to inIterable() should modify the previous sibling node instead of the
> "current" node, and in case a null named non iterable node is left in the
> leaf of the path, it should never be added.
> This behavior is not documented in the JSR-303 spec document, but
> ConstraintValidatorContext Javadoc gives information on how it should work."
> You can get the description of this behaviour here:
> care of the typo with city/country).

Hi Carlos,
  My local changes still pass our local tests of this nature, despite the TCK failures.  I've
just discovered the debugging profile in the tck-runner module, so I'll look into that and
report back.


> I don't have much time to look into it today, but I can say that I remember
> that behaviour as being a little counter-intuitive, but at that stage I
> centered on making the tests pass.
> Regards,
> Carlos
> On Tue, Sep 28, 2010 at 8:49 PM, Matt Benson <> wrote:
>> On Sep 28, 2010, at 2:36 PM, Carlos Vara wrote:
>>> Hi Matt,
>>> I remember having special trouble when working on the Path creation API
>> to
>>> make the tests pass. I also remember thinking the TCK was weird in the
>> way
>>> the nodes had to be created for the tests to pass.
>>> This night I will try to get time to take a look and update this thread.
>> Actually I have already finished a cut of the changes to make PathImpl et
>> al spec-compliant and they do then fail the TCK.  It would seem that either
>> the spec or the TCK needs to change to come into alignment with the other.
>> I am going to finish my changes up and attach them to a patch in JIRA so I
>> don't lose them.  :/
>> -Matt
>>> Regards,
>>> Carlos
>>> On Mon, Sep 27, 2010 at 11:08 PM, Matt Benson <>
>> wrote:
>>>> Hi guys,
>>>> I believe I have found a serious issue.  In section 4.2, the structure
>> of
>>>> a set of Path.Nodes is described almost as a footnote to the section
>>>> describing ConstraintViolation.  On rereading this section my
>> interpretation
>>>> is that bval-jsr303 currently implements association traversals
>> precisely
>>>> backward to the letter of the specification.  I am quite shocked that we
>> can
>>>> pass the TCK like this, but hopefully this means the TCK tests are
>> simply
>>>> string-based, since the alternative situation would be that the RI,
>> which
>>>> presumably passes the TCK, is flawed in a similar way to the Apache
>>>> implementation.  I'd also be glad to be educated on why I am mistaken.
>> My
>>>> issue is this:
>>>> The spec says that a constraint on the fourth author (i.e. "authors[3]")
>>>> would be represented by a not-in-iterable "authors" node followed by a
>>>> nameless node with index 3.  PathImpl would represent this as a single
>>>> "authors" node with index 3.
>>>> Likewise, the spec says that a constraint on the first author's company
>>>> ("authors[0].company") would be represented by a not-in-iterable
>> "authors"
>>>> node followed by a "company" node with index 0.  PathImpl represents
>> this as
>>>> an "authors" node with index 3, followed by a not-in-iterable "company"
>>>> node.
>>>> I wholeheartedly believe I have discovered a bona fide problem here and
>>>> will begin working to fix it.  Unless I am looking at the wrong
>>>> specification I can't imagine how I could be mistaken here, but please
>>>> review and let me know if I am in fact mistaken.
>>>> Thanks,
>>>> Matt

View raw message