Hard dependency on Gson

Config class holds a field private Optional<ObjectMapper> objectMapper = Optional.of(new JsonObjectMapper());

and JsonObjectMapper is based on Gson api and if Gson is missing in OSGi environment because most of the time we have Jackson, the class loading will fail. Of course we can install the Gson bundle into the OSGi runtime and it will work but when we already have Jackson present why would someone wants Gson.

I know there is an extension module available for Jackson but that does not remove the hard dependency on Gson, so a way to provide the kong.unirest.ObjectMapper implementation like kong.unirest.JacksonObjectMapper at runtime would be good to have.

There must be very good reasons to defaults to Gson but I still thought it is good to have a pluggable mechanism without a hard dependency on any JSON library.

JJWT - https://github.com/jwtk/jjwt has this approach, please have a look.

Thanks, Rakesh

[ryber]

This is complete as part of Unirest-4 which is in maybe the final release candidate, see https://github.com/Kong/unirest-java/discussions/429

[ryber]

Tried hacking on this a bit since i t’s like -3 outside. This is going to be hard. What I outlined above isn’t going to work. I’m going to need to abstract out gson itself