we kind of ack - me being alone ;) - we'll go with jsonp as first class
citizen so I guess you are right Eugen. My hope was to wrap jsonp to ensure
to the user a unified jsonb view.
Side note on that: anyone knowning from memory if we can access the
streamer in jaxb? I don't think so, maybe why I was not shocked to not
expose it in jsonb.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2016-05-10 19:55 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> About using writeName followed by writeXXX: it is prevented by the api.
> For example the writeValueXXX without the name as parameter can be called
> only once in the root context or in an array,
> https://github.com/json-processing-inofficial/jsonp/blob/master/api/src/main/java/javax/json/stream/JsonGenerator.java#L185
>
> Indeed we could have a wrapper that does this logic and then does the
> respective calls to the backed JsonGenerator, but I am not a big fan of
> this option. It adds another api and feels like a disagreement with what
> has been done in jsonp (be it good or bad), which I really see as the low
> level streaming pendent of jsonb.
>
>
>
>
> 2016-05-10 7:30 GMT-07:00 Romain Manni-Bucau <rmannibucau_at_tomitribe.com>:
>
>>
>> 2016-05-10 15:51 GMT+02:00 Roman Grigoriadi <roman.grigoriadi_at_oracle.com>
>> :
>>
>>>
>>>
>>> On 05/10/2016 03:37 PM, Romain Manni-Bucau wrote:
>>>
>>>
>>> 2016-05-10 15:26 GMT+02:00 Roman Grigoriadi <roman.grigoriadi_at_oracle.com
>>> >:
>>>
>>>>
>>>>
>>>> On 05/10/2016 08:14 AM, Romain Manni-Bucau wrote:
>>>>
>>>> Ok, let step back. Before all *technically* I fully agree with you. Why
>>>> I defend a different position is from my experience a lot of people will
>>>> not be able to use such an API so i'm trying to ensure our API is adopted
>>>> whatever use case we support.
>>>>
>>>> Whats wrong with JsonParser API from user perspective? If JsonStructure
>>>> is needed instead of event driven api, it can be provided by mapper API (as
>>>> Eugene mentioned). JsonParser will be at START_OBJECT position when passed
>>>> to deserializer, so user can get JsonStructure for whole deserializer
>>>> root/return type. Furthermore, according to JSONP master branch, looks like
>>>> there will be methods for getting JsonArray/JsonObject directly on
>>>> JsonParser since JSONP 1.1 release.
>>>>
>>>>
>>>>
>>> Proposal is just to add an abstract child already doing
>>> context.deserialize(JsonObject.class, parser) and giving as parameter
>>> the JsonObject instead of the parser. Making it direct and not requiring
>>> users to look for this or to know they have to pass JsonObject.class as
>>> parameter is good enough.
>>>
>>> But wouldn't it be redundant after JSONP 1.1, which has those already in
>>> JsonParser?
>>>
>>>
>>>
>>>
>> Maybe but it doesn't cost much and makes it an easier entry point for
>> several users so I think it does worth it.
>>
>>
>>> Secondly the fact jsonp doesnt support writeKey()writeValue() doesnt
>>>> prevent us to do it (we actually do since we have the key before the value
>>>> in the mapper model ;)).
>>>>
>>>> Didn't get this one, we do writeStartObject(String key), and
>>>> writeEndObject() in the mapper.
>>>>
>>>>
>>> In the API or the impl? Globally point is we can support a single
>>> serialize method as mentionned by Eugen.
>>>
>>> Ok, I missed the point.
>>>
>>>
>>>
>>>>
>>>> It means I think we can go for Eugen proposal BUT to support my case
>>>> too we would need a subclass/abstract impl giving the JsonReader
>>>> (read(parser, Object) doesn't work, see polymorphism thread).
>>>>
>>>> Would it be a good compromise?
>>>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>> 2016-05-10 0:46 GMT+02:00 Eugen Cepoi < <cepoi.eugen_at_gmail.com>
>>>> cepoi.eugen_at_gmail.com>:
>>>>
>>>>> Ahh damn I remember now... in jsonp we have a separate methods to be
>>>>> used inside objects which takes the key and others without the key, but you
>>>>> can't first write the key and then write the value...which sucks. I should
>>>>> have insisted more on that :p
>>>>>
>>>>> So in short my comment is irrelevant as I was assuming that we have
>>>>> writeName+writeValue methods in JsonGenerator...so yeah in this case there
>>>>> is no choice, we need serialize methods that take a key and another that
>>>>> doesn't... :(
>>>>>
>>>>> 2016-05-09 15:22 GMT-07:00 Dmitry Kornilov <
>>>>> <dmitry.kornilov_at_oracle.com>dmitry.kornilov_at_oracle.com>:
>>>>>
>>>>>>
>>>>>> I also think that passing jsonp parser/generator as an argument is
>>>>>>> OK. The question here is that we are forcing implementations to use
>>>>>>> parser/generator. What if (as Romain mentioned somewhere in this thread)
>>>>>>> some implementations will use reader/writer as a parsing mechanism? Shall
>>>>>>> we consider this option? Folks, I need you opinion here.
>>>>>>>
>>>>>>>
>>>>>> JsonReader/writer just deal with the full dom structures, to get a
>>>>>> dom structure one could simply do ctx.deserialize(JsonObject.class, stream).
>>>>>> So I think it is just fine and is the right thing to do: use the low
>>>>>> level jsonp api.
>>>>>>
>>>>>>
>>>>>> Agree.
>>>>>>
>>>>>> But there is another use case. What if we have a list inside an
>>>>>>> object we are serializing.
>>>>>>>
>>>>>>> public class Create {
>>>>>>> public List items;
>>>>>>> }
>>>>>>>
>>>>>>> For some reason we don’t want to serialize items list using
>>>>>>> context.serialize(“items”, crate.items, generator).
>>>>>>> We want to serialize each item manually in a cycle.
>>>>>>>
>>>>>>> generator.writeStartArray();
>>>>>>> for (Object item in crate.items) {
>>>>>>> // Ooops! We don’t have a method to write an object without a key in
>>>>>>> SerializationContext
>>>>>>> // It should be something like this
>>>>>>> *context.serialize(item, generator); // This is a new method to add
>>>>>>> I was talking about*
>>>>>>> }
>>>>>>> generator.writeEnd();
>>>>>>>
>>>>>>>
>>>>>> Not sure if I followed everything (I have been busy with other things
>>>>>> lately), but IMO the context should not provide different methods for
>>>>>> arrays, objects etc. Only one that takes an object, a generator and
>>>>>> eventually a type (if we want to allow a user to say serialize object of
>>>>>> type B but using his super type A). One could pass to it arrays, lists,
>>>>>> pojos, primitives, whatever he wants and it will get serialized/deser using
>>>>>> the registered serializers for that type.
>>>>>> I hope I am not adding more confusion here…if you want some code
>>>>>> examples let me know.
>>>>>>
>>>>>>
>>>>>> Yes, I think we have some misunderstanding here. Below I copied our
>>>>>> latest version of SerializationContext interface to make it clear. As you
>>>>>> see there are no methods for arrays, lists, etc. The method I was talking
>>>>>> about above is marked bold.
>>>>>>
>>>>>> public interface SerializationContext {
>>>>>>
>>>>>> /**
>>>>>> * Serializes arbitrary object to JSON, using current {_at_link
>>>>>> javax.json.stream.JsonGenerator} instance.
>>>>>> *
>>>>>> * @param key JSON key name
>>>>>> * @param object object to serialize
>>>>>> * @param generator JSONP generator to serialize with
>>>>>> * @param <T> Type of serialized object
>>>>>> */
>>>>>> <T> void serialize(String key, T object, JsonGenerator generator);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> * /** * Serializes arbitrary object to JSON, using current
>>>>>> {_at_link javax.json.stream.JsonGenerator} instance. * * @param
>>>>>> object object to serialize * @param generator JSONP generator to
>>>>>> serialize with * @param <T> Type of serialized object */ <T>
>>>>>> void serialize(T object, JsonGenerator generator);*
>>>>>>
>>>>>> /**
>>>>>> * Converts string value into provided type. String value has to
>>>>>> be single JSON value, not a part
>>>>>> * of a JSON document representing JSON object.
>>>>>> *
>>>>>> * @param obj object to convert to string
>>>>>> * @param generator JSONP generator to serialize with
>>>>>> * @param <T> type of object
>>>>>> *
>>>>>> * @return converted string value
>>>>>> * @throws javax.json.bind.JsonbException if conversion of given
>>>>>> type is not supported
>>>>>> */
>>>>>> <T> String convertDefault(T obj, JsonGenerator generator);
>>>>>> }
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>