Hi Dmitry,
Between the proposal the MixIn seems the cleaner to me but if we let
users provide their own class mapper (Class -> list of attributes)
then we don't need another model (MixIn).
That said I also like the CDI way - even if it can imply more API in
jsonb: Class becomes AnnotatedClass and you can wrap it, modify it
before the runtime processes it through an "Extension". We would then
get a config.registerExtension(new MyJsonbExt()) a bit like your
customizer but instead of working on classes through several method we
would get "events" or hooks for enriched typed:
AnnotatedClass onType(AnnotatedClass inClass); // inClass.getFields()
-> Collection<AnnotatedField>, same idea for methods etc...
Allows to chain extensions (do we reuse @Priority to order them?) and
make the mode even richer and multi-framework friendly IMO - for
instance cglib, openwebbeans, jpa provider can filter their own
internal fields on a proxy.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-11-09 10:11 GMT-08:00 Dmitry Kornilov <dmitry.kornilov_at_oracle.com>:
> Hi Experts,
>
> We are preparing a second draft of JSON-B spec. There are a few topics we
> still need to discuss. I'll create a thread for each topic in the next few
> weeks.
>
> Today lets start with third party objects.
>
> Use case:
>
> We have an extenal jar with classes we need to process. We cannot add any
> annotations to these classes. Default configuration doesn't process it the
> desired way.
>
> Options are:
>
> 1. Jackson like MixIn annotations
>
> For each third party class we want to customize an internal class/interface
> has to be created. This internal class has @Jsonb annotations defined the
> way how it should be in a third party class.
>
> More details:
> http://wiki.fasterxml.com/JacksonMixInAnnotations
>
> It covers most of the use cases and simple enough. The disadvantage I see is
> that configuration cannot be changed at runtime because conversion logic is
> defined in mix-in classes.
>
>
>
> 2. MOXy like external metadata format
>
> All customizations are defined in external json document. This document has
> predefined format. This document is processed during JsonbConfig creation.
> Something similar to this:
>
> JsonbConfig config = new JsonbConfig()
> .withMetadata(fileInputStream);
>
>
> More details:
> https://wiki.eclipse.org/EclipseLink/Examples/MOXy/EclipseLink-OXM.XML
>
> I see it more complicated than mix-ins approach. The advantage is that
> customizations can be created at runtime.
>
>
> 3. Provide customization API (runtime annotations)
>
> Define an API that allows adding customizations at runtime.
>
> Something similar to this:
>
> JsonbCustomizer customizer = new JsonbCustomizer();
> customizer.addJsonbNullableOnClass("package.ClassName", true);
>
> customizer.addJsonbPropertyOnField("package.ClassName", "fieldName",
> "value");
> customizer.addJsonbPropertyOnMethod("package.ClassName", "methodName",
> "value");
>
> JsonbConfig config = new JsonbConfig()
> .withCustomizer(customizer);
>
> I see it simple enough. Configuration can be created at runtime.
> Implementations can use this API to process external metadata files (like
> the MOXy one above).
>
>
> 4. Leave it as it is (not really an option)
>
> We already have adapters. The disadvantage is that it can be not flexible
> enough in cases where the same type has to be processed differently in one
> configuration. It also lacks runtime configuration.
>
>
> Lets discuss the options. Feel free to suggest more options.
>
> Thanks,
> Dmitry Kornilov