Hi Mark

2016-04-05 22:23 GMT+02:00 Mark Struberg <[email protected]>:
> Hi!
>
> I have a question regarding the behaviour of JsonReader. I don't like to know 
> how our impl behaves right now
>
> but what is expected by the specification.
>
> Currently our JsonReader always consumes the whole input. And it even blows 
> up if there is anything else on the stream. See JsonReaderImpl#readValue 
> ("Expected end of file",...)
>

Sounds right to me

>
> What I did expect is the following:
>
> The JsonReader basically consumes the JsonParser and makes JsonObject etc 
> from it.
>
> Now for what I was looking for:
> I was about using JsonParser and parse the stream manually. But sometimes I 
> need a full Object. Means my JsonParser might be positioned on the start of 
> an object ('{'). If I create a new JsonReaderImpl(jsonParser) and call 
> readObject() then it blows up. It doesn't go down the object tree, creates 
> JsonObjects and stops after it finishes THIS LEVEL. But instead it tries to 
> continue until there is no more element.
>

This is right too I think, ie JsonReader is a stream reader (until the end).

>
> The question now is: am I expecting the wrong behaviour?
>
>
> The reason why I'm asking is that the Mapper currently is a bit asymmetric. 
> It uses the streaming API (JsonGenerator) for writing objects but the tree 
> API (JsonReader) for reading objects back.
>
> Most of the time this doesn't matter for the end user, as all this is hidden 
> behind the Mapper. But for ObjectConverter it makes a difference. Of course 
> it will work, but it is not very obvious.
>
> Any ideas?
>

Yep, fork the few relevant part of reader (sorry but I'd like mapper
be independent of core) - aka parseObject(JsonObjectBuilder ) and
parseArray(JsonArrayBuilder ). Makes ~100 lines to fork solving this
smoothly IMO and linking the parser mapper reader can use and
converters which can need a MapperObject integration.

> LieGrue,
> strub

Reply via email to