[Bug Report] TypeResolver create a new ObjectMapper
instance, ignoring custom configurations
#3101
Labels
status: superseded
An issue that has been superseded by another
📌 Summary
GenericJackson2JsonRedisSerializer.TypeResolver
currently creates a newObjectMapper
instead of using an existing one.StreamReadConstraints
for handling large JSON strings.ObjectMapper
withmaxStringLength = 100MB
, theTypeResolver
still enforces a 20MB limit, causing deserialization failures.🔍 Steps to Reproduce
ObjectMapper
withStreamReadConstraints.maxStringLength = 100MB
GenericJackson2JsonRedisSerializer
for Redis serializationRedisTemplate
or@Cacheable
TypeResolver
creates a newObjectMapper
, which applies a 20MB limit, leading to:🚀 Expected Behavior
TypeResolver
should use the configuredObjectMapper
instead of creating a new one internally.StreamReadConstraints.maxStringLength = 100MB
should be respected when deserializing Redis data.🛠 Suggested Fix
TypeResolver
to accept anObjectMapper
instance as a constructor argument.null
, it should fall back to a default instance.📎 Relevant Code (Current Issue)
✅ Suggested Fix
🌍 Environment
📢 Additional Context
This issue causes Redis deserialization failures when handling large JSON payloads. Users configuring a custom
ObjectMapper
expect their settings to be respected, butTypeResolver
currently overrides them by always creating a new instance. Fixing this will ensure better configurability and prevent unexpectedSerializationException
errors.The text was updated successfully, but these errors were encountered: