Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kotlin: XmlMapper is not calling custom LocalDateTime serializer for JavaTimeModule #581

Open
martbab opened this issue Mar 9, 2023 · 3 comments

Comments

@martbab
Copy link

martbab commented Mar 9, 2023

NOTE: may be duplicate of #41.

Description:

In one of our projects we use XmlMapper to deserialize third-party XML to beans containing LocalDateTime instances. The XML stores local date and time in the configured timezone, and during deserialization we have a custom subclass of com.fasterxml.jackson.datatype.jsr310.deser.LocalDateTimeDeserializer which converts it to LocalDateTime value in UTC (which is a requirement of our system).

When implementing the inverse operation (serializing bean to XML conforming to third-party spec), I first implemented the custom subclass of com.fasterxml.jackson.datatype.jsr310.ser.LocalDateTimeSerializer doing the inverse conversion, so from UTC LocalDateTime to the LocalDateTime of configured timezone.

Both of them are registered as deserializer/serialized for LocalDateTime type in com.fasterxml.jackson.datatype.jsr310.JavaTimeModule instance.

During deserialization, I can verify that our custom implementation is called, but the inverse operation skips custom serializer and falls back to default com.fasterxml.jackson.datatype.jsr310.ser.LocalDateTimeSerializer every time.

This then forces me work around this by implementing serializer for the whole bean type, and do the conversion there.

Because the stuff is quite hard to explain, I have implemented a simple reproducer which you can clone and run included tests.

Steps to reproduce:

Library versions:

com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.14.2
com.fasterxml.jackson.module:jackson-module-kotlin:2.14.2
com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.14.2

Steps to reproduce:

Build the reproducer from this repo and run included tests.

Expected outcome:

All tests pass because registration of both custom serializer and deserializer of LocalDateTime type works.

Actual outcome:

Tests fail, with failures indicating that the built-in JSR310 LocalDateTime serializer is not overriden by custom one.

@pjfanning
Copy link
Member

Might be better to provide an actual java test case. Essays about issues can be misinterpreted and some times the essays turn out to be an incorrect summary.

@martbab
Copy link
Author

martbab commented Mar 9, 2023

Hello I filled in a repo with a test case which I created here: https://github.com/martbab/jackson-dataformat-xml-issue-581-reproducer

@cowtowncoder
Copy link
Member

Without knowing about details (and not having to dig deep), one thing I'd suggest is that in case of multiple modules registering a serializer/deserializer, later registration "wins"; so it may come down to making sure your custom (de)serializers are registered after JSR310 ones. XML module doesn't have overrides for (de)serializers so that shouldn't matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants