johnzon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Inconsistent Mapping Behavior...
Date Tue, 01 Jan 2019 21:16:24 GMT
Agree, we just nees to ensure to not expose more than today internals
probably but i dont see any blockers :)

Le mar. 1 janv. 2019 17:26, James Carman <james@carmanconsulting.com> a
écrit :

> Well, ideally, the recursive one and the root one would use the same logic
> to map a JsonValue/JsonNumber -> Integer object, right?  Perhaps we need to
> converge all this together and save ourselves some code.
>
> On Tue, Jan 1, 2019 at 11:19 AM Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
>
> > Hi James
> >
> > I likely need test cases to understand more the issue but long story
> short
> > one of the two method is recursive not the other so one must handle
> > primitives as root types and the other aq nested type. Historically
> > primitives were not possible root types so can be something to refind.
> >
> > Happy to review Jira+pr to be more accurate if needed.
> >
> > Le mar. 1 janv. 2019 16:31, James Carman <james@carmanconsulting.com> a
> > écrit :
> >
> > > I am looking at JOHNZON-177 and I have noticed that we seem to be
> mapping
> > > primitives inconsistently inside the same class.
> > > MappingParserImpl.toObject() and MappingParserImpl.readObject() both
> > > contain special logic for handling longs and ints.  Why wouldn't we
> want
> > to
> > > handle these types consistently regardless of where they're used
> (fields
> > or
> > > the root type)?
> > >
> > > I have included code to handle the overflow/underflow case with a nice
> > > error message and that works fine when I added tests to the
> > > DefaultMappingTest from the JSON-B module.  However, I found that
> > > MapperTest seems to already have similar tests for invalid long/int
> > > values.  As I trace the logic, it doesn't hit my new code.
> > >
> >
>

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