Hi James and guys, Is https://github.com/rmannibucau/johnzon/commit/23dfc58e301fb87bb72bc8bb4cdeb16d05666d4e what you had in mind?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 1 janv. 2019 à 22:16, Romain Manni-Bucau <[email protected]> a écrit : > 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 <[email protected]> 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 <[email protected] >> > >> 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 <[email protected]> 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. >> > > >> > >> >
