You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, JacoksonCBORProvider (maybe others) use ObjectMapper when resolving the mapper via the JAX-RS Provider functionality. This leads to it choosing JSON (via default ObjectMapper) in a variety of ways, none of which Jackson can assume all the blame for.
Using CBORMapper (or other specific derivations) would allow much easier selection of mappers for media types without them getting confused. Notably, JacksonYAMLProvider already does this, resolving specifically a YAMLMapper.
The use case is motivated by our recent breakage revelation that our custom configured CBORMapper was not being applied even though we register a ContextResolver for CBORMapper; the use of ObjectMapper during resolution fails to find it.
The text was updated successfully, but these errors were encountered:
Ok, this would make sense, especially given that by now every format module does have their own ObjectMapper sub-type -- in fact, there is even JsonMapper for explicit JSON-support (but plain ObjectMapper does, for legacy/compatibility reason, read/write JSON).
But the obvious question is whether change could be done in a backwards-compatible way. I think it can, will see if I can get a PR done.
Ah. This must have been due to legacy reasons: once upon a time CBOR- and Smile-formats did not have matching mapper sub-types, which is why configuration could not refer to those. This has long since (2.10?) been resolved, but things were not retrofitted.
Currently,
JacoksonCBORProvider
(maybe others) useObjectMapper
when resolving the mapper via the JAX-RSProvider
functionality. This leads to it choosing JSON (via defaultObjectMapper
) in a variety of ways, none of which Jackson can assume all the blame for.Using
CBORMapper
(or other specific derivations) would allow much easier selection of mappers for media types without them getting confused. Notably,JacksonYAMLProvider
already does this, resolving specifically aYAMLMapper
.The use case is motivated by our recent breakage revelation that our custom configured
CBORMapper
was not being applied even though we register aContextResolver
forCBORMapper
; the use ofObjectMapper
during resolution fails to find it.The text was updated successfully, but these errors were encountered: