JsonSerialization does not load all available modules from the classpath

[urferr]

Description

The ObjectMapper created provides only the default modules for serialization/deserialization, i.e. the module supporting serialization/deserialization for java datetime class is not loaded even if it is on the classpath.

This could be easily enhanced by adding
mapper.findAndRegisterModules();
in the static initializer for all the different ObjectMapper instances. Just a small change which would make life much easier.

Discussion

No response

Motivation

No response

Details

No response

[maxandriani]

I'm also struggling to add LocalDateTime (jsr310 module) to ObjectMapper...

[dominiktopp]

Hacky workaround: in any init method of any provider factory:

JsonSerialization.mapper.findAndRegisterModules();
JsonSerialization.prettyMapper.findAndRegisterModules();
JsonSerialization.sysPropertiesAwareMapper.findAndRegisterModules();

[thomasdarimont]

I just stumbled upon the very same problem.

I think the root cause is that the ObjectMapper does not scan for installed modules.
The ObjectMapper is initialized here:
https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/services/util/ObjectMapperResolver.java#L60

I just added a line like:

mapper = mapper.findAndRegisterModules();

After that a mapper.getRegisteredModuleIds() returned all modules on the classpath.

@pedroigor I think this is something that we should adapt as this is a common problem for uses when they use JSR 310 types in their custom JSON responses.

[pedroigor]

LGTM. As discussed, we also need to make sure the ObjectMapper instance is created only once at runtime.

[maxandriani]

LGTM. As discussed, we also need to make sure the ObjectMapper instance is created only once at runtime.

Ok, maybe we could create a hook system that people could create methods that receive ObjectMapper instance and add custom configurarions. So you guys can ensure a single instance but open for customization...

[thomasdarimont]

I think in the long run we should just rely on the jackson json customization option that quarkus provides.

For now let's focus on fixing the classpath module discovery :)

@pedroigor I debugged this a bit and found that the org.keycloak.services.util.ObjectMapperResolver#createStreamSerializer(..) method is currently called 3 times -> 2 times during server startup at runtime with the following stack traces (left first invocation, right second)

The third invocation happens here when the first requests is sent to Keycloak:

createStreamSerializer:60, ObjectMapperResolver (org.keycloak.services.util)
<init>:43, ObjectMapperResolver (org.keycloak.services.util)
doCreate:-1, ObjectMapperResolver_Bean (org.keycloak.services.util)
create:-1, ObjectMapperResolver_Bean (org.keycloak.services.util)
create:-1, ObjectMapperResolver_Bean (org.keycloak.services.util)
createInstanceHandle:119, AbstractSharedContext (io.quarkus.arc.impl)
get:38, AbstractSharedContext$1 (io.quarkus.arc.impl)
get:35, AbstractSharedContext$1 (io.quarkus.arc.impl)
get:32, LazyValue (io.quarkus.arc.impl)
computeIfAbsent:69, ComputingCache (io.quarkus.arc.impl)
computeIfAbsent:19, ComputingCacheContextInstances (io.quarkus.arc.impl)
get:35, AbstractSharedContext (io.quarkus.arc.impl)
get:-1, ObjectMapperResolver_Bean (org.keycloak.services.util)
get:-1, ObjectMapperResolver_Bean (org.keycloak.services.util)
beanInstanceHandle:554, ArcContainerImpl (io.quarkus.arc.impl)
beanInstanceHandle:534, ArcContainerImpl (io.quarkus.arc.impl)
beanInstanceHandle:567, ArcContainerImpl (io.quarkus.arc.impl)
get:331, ArcContainerImpl$3 (io.quarkus.arc.impl)
get:328, ArcContainerImpl$3 (io.quarkus.arc.impl)
create:58, BeanContainerImpl$1 (io.quarkus.arc.runtime)
createInstance:27, ArcBeanFactory (io.quarkus.resteasy.reactive.common.runtime)
getContextResolver:71, ContextResolvers (org.jboss.resteasy.reactive.server.model)
getContextResolver:63, ProvidersImpl (org.jboss.resteasy.reactive.server.jaxrs)
getContextResolver:-1, QuarkusContextProducers_ProducerMethod_providers_HZqlmFyAJ9hlyMcrIzRlosoXjKw_ClientProxy (jakarta.ws.rs.ext)
getEffectiveMapper:130, FullyFeaturedServerJacksonMessageBodyWriter (io.quarkus.resteasy.reactive.jackson.runtime.serialisers)
writeResponse:58, FullyFeaturedServerJacksonMessageBodyWriter (io.quarkus.resteasy.reactive.jackson.runtime.serialisers)
invokeWriter:216, ServerSerialisers (org.jboss.resteasy.reactive.server.core)
write:106, DynamicEntityWriter (org.jboss.resteasy.reactive.server.core.serialization)
handle:32, ResponseWriterHandler (org.jboss.resteasy.reactive.server.handlers)
invokeHandler:147, QuarkusResteasyReactiveRequestContext (io.quarkus.resteasy.reactive.server.runtime)
run:147, AbstractResteasyReactiveContext (org.jboss.resteasy.reactive.common.core)
runWith:582, VertxCoreRecorder$14 (io.quarkus.vertx.core.runtime)
run:2513, EnhancedQueueExecutor$Task (org.jboss.threads)
run:1538, EnhancedQueueExecutor$ThreadBody (org.jboss.threads)
run:29, DelegatingRunnable (org.jboss.threads)
run:29, ThreadLocalResettingRunnable (org.jboss.threads)
run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
run:833, Thread (java.lang)

Subsequent requests don't call the method...

Do you have an idea what the first and second invocation is? (_Bean vs _ClientProxy - perhaps we need to supress some CDI magic here...)

[thomasdarimont]

@pedroigor here is a PR with a fix: #29360