Vert.x 4 offers an SPI mechanism that would allow sharing the ObjectMapper between Quarkus and Vert.x. Thus, user customization would also be applied to object mapped to JSON from Vert.x.
Implementation ideas
The Jackson extension (runtime) could depend on Vert.x core (optional dependency) and implement the SPI
The SPI implementation would retrieve the managed ObjectMapper using:
The Jackson would check the availability of the Vert.x capability and if so register the SPI to be available in native mode.
Also, it should make sure that the ObjectMapper does not get removed by Arc, as Arc cannot detect such a usage.
The SPI implementation should register the Vert.x module:
SimpleModule module = new SimpleModule();
// custom types
module.addSerializer(JsonObject.class, new JsonObjectSerializer());
module.addSerializer(JsonArray.class, new JsonArraySerializer());
// he have 2 extensions: RFC-7493
module.addSerializer(Instant.class, new InstantSerializer());
module.addDeserializer(Instant.class, new InstantDeserializer());
module.addSerializer(byte[].class, new ByteArraySerializer());
module.addDeserializer(byte[].class, new ByteArrayDeserializer());
module.addSerializer(Buffer.class, new BufferSerializer());
module.addDeserializer(Buffer.class, new BufferDeserializer());
We need to make sure that the Instant and byte[] serializer/deserializer does not conflict with the user's code.
Testing can be done by registering a special module and use Json.decode and Json.encode methods.
Description
Vert.x 4 offers an SPI mechanism that would allow sharing the
ObjectMapper
between Quarkus and Vert.x. Thus, user customization would also be applied to object mapped to JSON from Vert.x.Implementation ideas
ObjectMapper
using:ObjectMapper
does not get removed by Arc, as Arc cannot detect such a usage.Json.decode
andJson.encode
methods.Related to #14779
https://github.com/quarkusio/quarkus/issues/15031
$upstream:15031$