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