GH-10058: Add Jackson 3 (de)serializer support

[anthologia]

Related to: #10058

• Add Jackson3-compatible messaging (de)serializers
• Add Jackson 3 messagingAwareMapper() support
• Maintain existing Jackson 2 functionality

I thought about splitting this into separate PRs ((de)serializers + messagingAwareMapper() support), but figured it'd be easier to review as one. It's a bit large though - apologies for the extra work! 😅

Now, I have a few questions..

Package Structure

With many Jackson 2 / Jackson 3 classes in the same package, how about reorganizing Jackson 2 into sub-package?

org.springframework.integration.support.json/ ├── jackson2/ 

Copyright and Authors

When refactoring the classes, I moved existing impls and created new ones, following the team's previous decision:

After team discussion, we prefer to have this as a JacksonJsonObjectMapper instead.
And try to keep the rest of API without a number as long as we have that Jackson2 variants.

Originally posted by @artembilan in #10160 (comment)

E.g., :

• *JacksonDeserializer → *Jackson2Deserializer (Jackson 2 support)
• Updated *JacksonDeserializer for Jackson 3 support

I've attempted to update @author and copyright year appropriately, but please review if they're handled correctly.

Docs

Currently, Many docs (e.g., redis.adoc) references the default class names:

Starting with version 4.3.10, the Framework provides Jackson serializer and deserializer implementations for Message instances and MessageHeaders instances — MessageJacksonDeserializer and MessageHeadersJacksonSerializer, respectively.

With this PR, we now have version-specific implementations:

• Jackson 2: MessageHeadersJackson2Serializer
• Jackson 3: MessageHeadersJacksonSerializer

Should we update docs to reflect current impl(Jackson 2) or keep it for 7.0 release since Jackson 3 will be the default?

[artembilan]

*JacksonDeserializer → *Jackson2Deserializer

thank you for the effort !
I’ll take a look tommorow in details, but I think this is a wrong direction.

we develop here a library for target project to rely on the API. We cannot break anything just because. It could be possible in target product where no one depend on your public API. With frameworks and libraries we don’t have such a liberty.
Therefore renaming existing classes, or moving them to different packages is wrong direction for us.
my apologies that my comment about naming was not so clear. Let me try again!
We only deprecate existing classes. We name new classes without a number, as much as possible. No need in a new package since deprecated classes will be removed in next version.
Again: we need to keep in mind that our code is used to compile other projects: breaking an API so dramatically is not acceptable.
Please, revise your solution.

[anthologia]

Thank you for taking the time to review this on the weekend !

I apologize for not fully considering that I'm contributing to a widely-used library. At my job, I work on middleware primarily focusing on backward compatibility for end-user functionality, but I hadn't deeply thought about the compatibility of public APIs that other projects depend on. I'll be much more careful to consider API dependencies and backward compatibility in my contributions.

For easier review, I'll revert *Jackson2Deserializer back to *JacksonDeserializer and add *Jackson3Deserializer instead. I'd appreciate any further guidance when you have a chance !

[artembilan]

Thank you for the effort!
Please, keep in mind that Jackson 2 will be deprecated.

I even wonder if we should do that right now, so then it will become more clear what to implement and where to migrate in tests. I don't say to do that in your current PR, but just an idea for the next step (if any).

Thank you!

[anthologia]

Thank you for the guidance!

It seems like we're getting closer to the point where Jackson 2 deprecation makes sense. I think we maybe need to add JsonPropertyAccessor support first.

As you mentioned previously, we'll likely be blocked by Jackson 3 migration in other projects. I'm not entirely certain, but from what I've checked, it appears to be Spring Kafka's DefaultKafkaHeaderMapper.

I see you're also a Spring Kafka maintainer. If needed, I'd be happy to help with migration in other projects too. Feel free to ping me on the relevant issues if my contribution would be helpful ! 😁

[artembilan]

Sure thing, @anthologia !

Here is Spring Kafka part: spring-projects/spring-kafka#3930
And if you are interested this is Spring AMQP part: spring-projects/spring-amqp#3117

[anthologia]

I'm not entirely familiar with these projects, but I'd be happy to give both a shot based on what I've learned here!

What's the expected release timeline for AMQP?

[artembilan]

What's the expected release timeline for AMQP?

For AMQP that was a PR from me to review.
If you want.
Nothing to do over there.
We have milestone in a couple weeks.
But all the plans for Jackson 3 migration are due on this November.
So, we have a plenty of time to clean up as maximum as we could.

Thank you for your help with all of this!

[artembilan]

Very good!
Just final nit-pick review.
Thank you!