It would be beneficial to have this, there has been no work around for quite some time now.

This merge would be very handy, thank you @EL-Greco-Domi

Any thoughts why this fails on Java 7, but not 8?

com.auth0.jwt.JWTCreatorTest > shouldAcceptCustomClaimOfTypeObject FAILED
    java.lang.AssertionError at JWTCreatorTest.java:339

Please check the open/closed issues regarding this same matter. This is definitely something we don't want to accept in a generic way. If you still want to try, an implementation we suggested back then is detailed here.

Hi,
sorry I was quite busy.

Regarding your concerns in the linked issue:
I do understand that we can't guarantee that the custom objects will be serialized in a way the user wants, but it could be that the default handling of the ObjectMapper is excatly what the user wants, and limiting his choice just because we could handle some Objects wrong is IMHO just too restrictive.
I also understand that you don't want to force a specific library onto users, but for the sake of usability it would be really handy to be able to register custom serializers, either as a method on one of the library classes or using the @JsonSerialize-Annotation.
Of course all of the above could be achieved by your suggestion of allowing Maps with the standard Java-Types, but that leads to just one result, the user is forced to implement the JSON parsing of custom objects by mapping his object's members into the according java types and putting them in a Map at the right position, although his custom object would be handled by ObjectMapper just fine.

If you really really don't wont to open up the library, there still is the possibility to create an own interface which is about the same like the one of jackson (StdSerializer), so just like this:

public interface ObjectSerializer<T> {

	public String serialize(T item);
	
	public Class<T> getClassToHandle();
}

A user can pass custom objects, if he's unhappy with the result he can register custom serializers which extend this interface. we can then wrap his custom serializer inside a StdSerializer and pass it to the ObjectMapper as serializer for the specified class. Using this way we don't force a specific library onto the users and still have the benefits of being able to use custom objects.

Cheers,
Dominic

@EL-Greco-Domi Yeah that could work out. I'll add this to our backlog for discussion. In the meantime, I'll leave this issue open as a reminder.

Jackson ObjectMapper supports converting objects directly to and from Map in a single line of code, so implementing a customer serializer would perhaps be more work and thus less convenient @EL-Greco-Domi?

Performance is not an issue either.

I suggest rather creating an 'extension' artifact for exposing this kind of inner workings, i.e. java-jwt-jackson-extension or something like that.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have not received a response for our team (apologies for the delay) and this is still a blocker, please reply with additional information or just a ping. Thank you for your contribution! 🙇‍♂️