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
