Apply JSON-B customizations to existing (i.e. 3rd party) classes

[hei1233212000]

In the application, you may need to serialize/deserialize some objects which come from 3rd party library. So that we cannot put JSON-B annotaions on it.

For resolve this issue, just like some IoC framework, support XML configuration would be valuable. So, any plan for this kind of enhancement?

Thank you.

[aguibert]

I think applying JSON-B metadata to objects that the developer is not able to modify is a good case to have covered. However, I would be strongly opposed to any sort of XML-based configuration, especially being as this is for a JSON standard. Ideally we can come up with some sort of java-based configuration mechanism in a future version of the spec.

[rmannibucau]

+1 for a java API, in johnzon we called it accessmode and it enables to map the instantiator, read and write properties. Guess jsonb can get the same in its builder. Another use case is to bridge an api, like supporting jaxb api to produce json like jettison does.

[m0mus]

I agree. We should provide an ability to configure JSONB in Java code. The functionality should cover all customizations/configuration provided by annotations. Also, JsonbConfig should support reading configuration from external sources using MicroProfile configuration or Config JSR which is in development now.

[rmannibucau]

Also, JsonbConfig should support reading configuration from external sources

To clarify: what I had in mind was JSON-B being able to read a JSON holding its configuration, so supporting any external tool should be as trivial as: jsonbConfig.withMappingConfiguration(myJsonConfig). myJsonConfig should be supported as being JsonObject, String or JsonbMapping (I assume we should be good enough to use ourself first).

[aguibert]

what would be the value of holding JSON-B config in JSON format? Could you include a sample of what you had in mind?

If we need to do nesting in config, I agree JSON would be preferable. But IMO the simplest way to do config is just key/value pairs, and if config is just key/value pairs then JSON format is overkill.

[rmannibucau]

Class > field > annotations, a bit like bval does in xml.

Key pairs is fine while it is set through a single property on jsonbconfig and not read by key in another backend

[aguibert]

Consider the following data model class:

    public static class Person {
        public String name;
        public LocalDate birthDate;
        public LocalDate deathDate;
    }

We could apply @JsonbDateFormat(JsonbDateFormat.TIME_IN_MILLIS) at the class level, or the property level.

In JSON, config might look like this:

{
  "com.example.Person" : {
    "@JsonbDateFormat" : "##time-in-millis",
    "properties" : {
      "deathDate" : { 
        "@JsonbDateFormat" : "##default"
      }
    }
  }

But we could more concisely represent this information as key/value pairs like this:

com.example.Person/JsonbDateFormat="##time-in-millis"
com.example.Person.deathDate/JsonbDateFormat="##time-in-millis"

[rmannibucau]

Outch, why not just keeping it as it is in java? One object per annotation, one object per class etc...

Also your concisely option breaks readability but also the one value point (keep in mind mp config will host multiple jsonb configs as today so you must use at least a prefix. Now i clearly prefer the first option which is mpconfig friendly and jsonbconfig friendly without any coupling vs second option which is coupled.

Ps: dont forget jakata will likely be closer of jakata.config than microprofile since it should superseed it at the end so withMappingConfig(model) is good. Then json or properties is not very important, just a consistency point with the spec itself but properties are part of java.se so no big deal if using the common dot notation and not a specific slash one ;).

[aguibert]

I was chatting with my co-worker, @njr-11, on this and he raised a good argument that there shouldn't be any need to have externalized JSON-B config that can be overridden at deployment time. Really, all of the JSON-B configuration should be taken care of by the application developer who can either:
A) apply JSON-B annotations directly to the class/fields/methods (does not work for the 3rd party model classes)
B) apply JSON-B annotations at runtime programatically (must be used for 3rd party model classes)

[rmannibucau]

How does B work for not managed classes? Frameworks use jsonb to store data in a database or so but the app server is not even aware of it. It would also be good to work in SE (A) otherwise adoption will not be there IMHO.

That said I am also not super big fan of the config solution, it is not code driven. What about the model alternative, ie you can bind a class as being the model for another one, only the shape is taken into account:

 jsonbconfig.withModel(MyClass.class, MyModel.class)
//...
jsonb.toJson(out, myClassInstance) // uses MyModel metadata

This is close to jackson view for example. It does not require to invent a new config model.