bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Vara <bashfl...@gmail.com>
Subject Re: Urgent problem with PathImpl
Date Tue, 28 Sep 2010 21:52:34 GMT
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 <gudnabrsam@gmail.com> 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 <gudnabrsam@gmail.com>
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message