Use MP/Jakarta Config for default JsonbConfig configuration

[aguibert]

trafficstars

It should be possible to configure default values for JsonbConfig instances using MP/Jakarta config.

For example, if an application initialized a default JSON-B configuration like this:

new JsonbConfig()

With the properties:

jsonb.formatting=true
jsonb.encoding=UTF-16

It would be equivalent to specifying the following:

new JsonbConfig()
  .withFormatting(true)
  .withEncoding("UTF-16");

If a JsonbConfig explicitly defines a configuration value, it takes precedence over any MP/JEE Config values. For example, using the same properties file above, and the following code:

new JsonbConfig()
  .withEncoding("UTF-32");

The resulting properties would be encoding=UTF-32 (explicitly defined) and formatting=true (from MP/JEE Config)

Configuration that requires instances of classes could also be supported, for example:

jsonb.adapters=com.example.MyAdapter,com.example.FooAdapter
jsonb.propertyVisibilityStrategy=com.example.MyVisibilityStrategy

For these cases, it would be required that the referenced classes have default constructors in order to be globally configured via MP/JEE Config. If they do not have default public constructors, an error would be thrown.

NOTE: Jakarta Config is not an official spec yet, but it is being proposed for Jakarta EE 9

[aguibert]

Part of #168

[rmannibucau]

Let precise the issue referencing it does not handle:

 new JsonbConfig()

But default managed instances:

@Inject
@JsonbInstance // todo find a better name
private Jsonb jsonb;

The difference is that it is:

1. backward compatible: a currently working app creating programmatically instances would get a new encoding, adapter etc if not which breaks apps, even simple config as formatting does.
2. better fits user expectations: being frictionless providing a default instance enables to avoid the user to produce it. My recommendation is to make jsonbconfig a bean with a classifier (cause it can already exist), a jsonb instance too (still with a classifier for backward compat) and create the jsonb instance from the jsonbconfig bean. This way the default config can be setup from any config, user can override it in a custom fashion if needed and jaxrs can look it up for endpoint if nothing else is configured.

[aguibert]

backward compatible: a currently working app creating programmatically instances would get a new encoding, adapter etc if not which breaks apps, even simple config as formatting does.

How does this break backwards compatibility? The only way I see it breaking backwards compatibility is if users happened to have the to-be-spec-defined properties already defined in their env/properties, such as: jsonb.formatting=true

As long as existing applications do not have jsonb.* properties defined, there should be no backwards compatibility issue. I doubt any such configurations exist already.

[rmannibucau]

Current config would be overriden, it implies a tons of regressions....

Also jsonb.* are already naturally used since it is the spec naming.

mp.jsonb.* sounds more microprofile but point about backward compat is still relevant until you respect the managed instance solution.

[aguibert]

current configuration would only be overridden if environments happen to specify the exact jsonb.* property names we choose, which is very unlikely and therefore we should not be concerned with this scenario.

[aguibert]

Perhaps we can wait and see what the naming convention is for Jakarta Config properties. If we are concerned with the property names colliding, we could qualify them such as: jakarta.<SPEC>.<PROPERTY>=<VALUE>

[rmannibucau]

Ok, take an app working doing some custom build of jsonb instances, add mp support, redeploy, it is broken cause your explicit config is overriden. If not enough for you, now assume you want to customize one instance, how do you do? It just does not work...and this is real apps cases.

[aguibert]

Ok, take an app working doing some custom build of jsonb instances, add mp support, redeploy, it is broken cause your explicit config is overriden. If not enough for you, now assume you want to customize one instance, how do you do?

Two things here:

1. It would only break if an app was setting the same properties we chose (e.g. jakarta.jsonb.formatting=true. Are you suggesting that existing apps are already setting config properties with the jakarta.* namespace?
2. In the original issue summary I suggested the opposite -- that MP Config would not override explicitly defined config: If a JsonbConfig explicitly defines a configuration value, it takes precedence over any MP/JEE Config values.

[rmannibucau]

1. Forget any already setting properties and give it a try, the support of new JsonbConfig is just not doable without a breaking change nobody wants
2. Same, implicit config is used config, cf 1.