David Yu

On Thu, Feb 21, 2019 at 4:40 PM Koen Serneels wrote: > Thanks, I will look into this. Some questions about this; > > 1. > > Isn't it bizarre...

Can you try using `1.8.0-SNAPSHOT` and see if those errors persist?

Because merging is a common use-case of protobuf, the behavior is always to merge an existing field. If you are to purely use this for java serialization (no compatibility with...

Protobuf writes enums by their number/ordinal. That's what protostuff does. Json is a supported _format_ which recieves that number and writes a json number.

enums_by_name is an api-level change which affects all the supported formats. You want only enums_by_name enabled for json but that is not possible.

Protostuff treats your pojo as a map hence it doesn't serialize its fields (just the entries). If your pojos implement Map/Collection/List, register them on startup/init like this: ``` RuntimeSchema.map(TestMainData.class, TestMainData.class);...

Do the latter. Every class that extends it (or directly implements Map/Collection/List) need to be registered. Let me know if you still have problems after doing that.

Ok. There were internal changes needed to make this work. Try using 1.0.12-SNAPSHOT and instead of calling `RuntimeSchema.map`, do: ``` RuntimeSchema.register(TestMain.class); // lazy registration ``` 1.0.12 should be available in...

> Is it because there is different handling of deserialization of Enum object than a java class? Yes. You can solve that using delegates - https://protostuff.github.io/docs/protostuff-runtime/delegate/

@Vishv19 you can upgrate to 1.0.12 safely