General use case is: how to support structure (json) enrichment during
serialization process
Examples are:
- polymorphism
- framework metadata (MDC like)
- contextual data enrichment (transactionId is a common use case)
- ...
We can't support all cases in the spec in a specific manner (like
TypeWrapper would for polymorphism). So adapters need to be enriched if we
want to allow the end users to keep their model business driven (ie without
these metadata).
Today adapters don't allow to deserialize based on the metadata which can
be an important thing for conditional data or contextual data
(applicationId and/or transactionId and/or type can be used to retrieve the
right model to cite a simple case). You can also use these metada at that
moment (only one you have them) to populate contextual data used later on.
Finally there are numerous case where to integrate with X you need to
enrich your model but you don't control the model in your own code so you
need some global adapters to do the wrapping/unwrapping to not break
existing code. To summarize serialization is not a big deal today but
deserialization would need access to the JsonObject. Once you got it for
symmetry and sanity of the API serialization needs to be able to do the
"same" and write field itself. Last point JsonObject works but breaks the
mapper side so we need an additional method to map a JsonObject directly in
the context we pass to this new kind of adapter.
Hope it is clearer.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2016-04-01 11:01 GMT+02:00 Roman Grigoriadi <roman.grigoriadi_at_oracle.com>:
> Hi,
>
> I think we need to reconsider what are the usecases (besides
> polymorphism), that cannot be handled efficiently with adapters. Can you
> please provide such code examples describing the limitations of adapters in
> their current state? I still have a feeling I am not on the same note, to
> render what the problem with adapters actually is.
>
> Thanks,
> Roman
>
>
> On 04/01/2016 08:00 AM, Romain Manni-Bucau wrote:
>
> Hi Dmitry
>
> Think the topic is not polymorphism but advanced adapter. Polymorphism is
> one example of that only.
>
> The last proposal of Roman needs some rework - see my last mail with
> JsonbObjectBuilder - but we move forward and in the right direction: making
> easy from/to map to jsonp objects - including objects directly and not
> primitives only - is what makes sense and gives us all the flexibility.
> Makes a bit harder to implement trivial cases but here it is easy to add to
> the spec an abstrat class skipping jsonp (for object to primitive mapping
> if we judge it too verbose using a JsonValue bit I think it can be optional
> for jsonb 1.0)
>
> I am really for fixing adapter API and not making polymorphism a
> particular case of the spec.
>
> Le 31 mars 2016 23:46, "Dmitry Kornilov" <dmitry.kornilov_at_oracle.com> a
> écrit :
>
>> Hi,
>>
>> I see that polymorphism discussion is still on. I am planning to publish
>> a second draft soon so we need to make a decision rather sooner than later.
>>
>> I see that we have three options:
>>
>> 1. We don’t support polymorphism in this version of the spec. We still
>> can add it later.
>>
>> 2. We add PolymorphicAdapter suggested by Roman to the spec.
>>
>> 3. We create a special annotation @JsonbPolymorphism (or other name)
>> which will enable polymorphic handling of the annotated type. It can accept
>> a list of supported children as a parameter. Empty list means all children.
>>
>> Sample:
>>
>> public class Foo {
>>
>> @JsonbPolymorphism
>> Animal animal;
>> }
>>
>> For me the third option looks the most reasonable one. What do you think?
>>
>> Thanks,
>> Dmitry
>
>
>