Le 10 mai 2016 21:37, "Dmitry Kornilov" <dmitry.kornilov_at_oracle.com> a
écrit :
>
> Here are my two cents:
>
> We don’t need any wrappers. It just adds complications to the API.
Ok for 1.0. Any way to track it as a backlog in case it comes back later?
> I agree to add default JsonbSerializer::isReentrant() method indicating
that serializer can be called the recursive way.
>
This is not needed as mentionned. ConvertDefault is suspicious too IMO and
could be removed from both sides (deser/ser).
> If it’s OK I’ll consider it as finished. I will commit a modified spec
and be ready to submit a public draft at the end of this week.
>
> Dmitry
>
>> On 10 May 2016, at 20:05, Romain Manni-Bucau <rmannibucau_at_tomitribe.com>
wrote:
>>
>> 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>:
>>>>>>>>>
>>>>>>>>> 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>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>