Hi again Matt, this is the issue in which I added the changes to pass the tests: https://issues.apache.org/jira/browse/BVAL-29
>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: http://download.oracle.com/javaee/6/api/javax/validation/ConstraintValidatorContext.html#buildConstraintViolationWithTemplate%28java.lang.String%29(take care of the typo with city/country). 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 <[email protected]> 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 <[email protected]> > 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 > >
