Closed jimmyjames closed 1 year ago
Looks good to me. But I am wondering whether we should use this through an interface so that we can provide an option to use a custom serializer/deserializer?
Use of concrete class feels it could be hard to move things around if required in the future.
Looks good to me. But I am wondering whether we should use this through an interface so that we can provide an option to use a custom serializer/deserializer?
Can you share an example of what you are thinking? The class is intended for internal usage only (can add a commit to clarify the javadocs), so if we need to add or change functionality in the future we can.
I was wondering something like where we use an interface
public class Auth0ObjectMapper {
public String deserialize();
public Object serialize();
}
So that we can provide it as an option if users want a custom instance to use like below
Auth0ObjectMapper = new Auth0ObjectMapper {
private Gson gson = new Gson();
...
}
auth.useMapper(customMapper)
Adding a hook for custom serialization/deserialization isn't something this PR aims to provide. It's not currently in our backlog but could certainly be added if it's something we want to consider for v2 or beyond.
ObjectMapper
is thread-safe and should be reused. This PR adds a new classObjectMapperProvider
, which returns a singleton instance for internal usages to process JSON data.