[
https://issues.apache.org/jira/browse/CAMEL-22857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137895#comment-18137895
]
James Netherton commented on CAMEL-22857:
-----------------------------------------
The way I plan to approach this is to replicate what PR #21800 did, but do
separate PRs for upgrades to third party libraries.
Some things to note and think about:
*1. camel-jackson3 components use the Jackson 3 defaults*
The visible ones: unknown properties are ignored, properties are written
sorted, dates and durations are written as ISO text, trailing content fails,
null for a primitive fails, enums use toString(). A feature can be restored
with configuration options enableFeatures/disableFeatures, or for REST binding
with dataFormatProperty("json.in.enableFeatures", "FAIL_ON_UNKNOWN_PROPERTIES").
The one that matters: a REST route with JSON binding no longer rejects a body
that does not match its POJO. No 400, the route gets a POJO with empty fields.
The 4.24.0 upgrade guide will document it, but it is a relaxed default that
folks should be aware of.
Spring has a config option spring.jackson.use-jackson2-defaults. We could
eventually consider adding a similar option to each jackson3 component, so
users have a way to easily restore the jackson 2 defaults.
*2. Internal mappers (the ones components use to talk to external APIs, parse
secrets, write files) keep the Jackson 2 defaults via
JsonMapper.builderWithJackson2Defaults()*
What we send and store does not change. About 100 call sites, we could audit
this later and either drop builderWithJackson2Defaults or apply what defaults
the component needs.
*3. One data format name, two artifacts*
A route that says marshal().json() or library: Jackson resolves the data format
named "jackson", and both camel-jackson (Jackson 2) and camel-jackson3 (Jackson
3) provide it. Today, with both on the classpath, whichever comes first wins,
which is undefined and differs between Maven, JBang and the runtimes. I plan to
make Jackson 3 'win' whenever both are present, so an application that has not
cleaned up its dependencies gets the 4.24 default line rather than a coin toss.
The upgrade guide will say to declare only one of them, and that a custom
ObjectMapper in the registry is only picked up by the data format of the same
Jackson version.
*4. Jackson 3 changed its input guards and we are not restoring the old ones*
Jackson parses with limits against hostile input: Jackson 2 allowed nesting up
to 1000 levels and strings up to 20 million characters; Jackson 3 allows 500
levels and 100 million characters, and applies the nesting limit on write as
well. A document nested deeper than 500 levels now fails to read or write, and
a larger string is now accepted. builderWithJackson2Defaults() does not restore
these limits, so they apply to every component on Jackson 3, internal mappers
included. Restoring them would be per-mapper configuration in about 100 places
for a depth no real payload reaches, so the upgrade guide documents the new
limits once instead.
*5. Jackson-based Kamelets*
There is a 'chicken and egg' scenario in relation to camel-kamelets. kamelets
are released after the Camel core is released. Thus Camel would ship with the
'out of date' 4.23 kamelets.
For the Jackson-based Kamelets to work, users would need
--kamelets-version=4.24.0. The alternative of trying to keep both kamelets 4.23
and 4.24 working on one classpath through the transition, is machinery we would
carry for one release and then remove, so I would rather not do that as it adds
additional complexity.
> Add support for Jackson 3
> -------------------------
>
> Key: CAMEL-22857
> URL: https://issues.apache.org/jira/browse/CAMEL-22857
> Project: Camel
> Issue Type: Task
> Components: camel-jackson
> Reporter: Thomas Cunningham
> Assignee: James Netherton
> Priority: Major
> Fix For: 4.x
>
>
> Spring Boot 4 utilizes Jackson 3 by default, we should look at moving Camel
> to Jackson 3
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
