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

XML module not registered correctly when setting a custom SerializerFactory #678

Closed
SimonCockx opened this issue Oct 24, 2024 · 6 comments
Closed
Labels
2.18 Issues planned at earliest for 2.18

Comments

@SimonCockx
Copy link
Contributor

SimonCockx commented Oct 24, 2024

I'm using a custom SerializerFactory as follows.

ObjectMapper mapper = new XmlMapper().setSerializerFactory(MySerializerFactory.INSTANCE);

I noticed that in the constructor of XmlMapper, the default XML_MODULE is registered, which also configures the SerializerFactory. Since I'm overriding it after constructing, this configuration is lost, resulting in different behaviour, which is very confusing.

I currently don't see any way for registering my custom SerializerFactory before the XML_MODULE is registered. Is this intended? It seems error-prone.

My current workaround:

ObjectMapper mapper = new XmlMapper((JacksonXmlModule) null)
    .setSerializerFactory(RosettaSerialiserFactory.INSTANCE)
    .registerModule(new JacksonXmlModule());
@cowtowncoder
Copy link
Member

I think that overriding of SerializerFactory is very rare thing, this is probably the first time I've heard users doing that. So I don't think the problem here was anticipated.

It might help if I understood your use case better: why are you overriding SerializerFactory?

@SimonCockx
Copy link
Contributor Author

See my comment in #676 (comment).

At the moment I'm using a custom SerializerFactory to "hack in" some solutions to that issue. :)

@cowtowncoder
Copy link
Member

Ah ok. Yes, we should make it possible to configure SerializerFactory even with XML module. Right now I am bit overloaded with Jackson work so I may not have time to work on this, BUT, if you had time to maybe propose a pr, I'd make sure find time to review and help with it.

Without remembering full details, I suspect JacksonXmlModule should expose configurability of SerializerFactory -- it seems to be passed to XmlSerializerProvider (sub-class of default SerializerProvider) as it's, well, required.

But I guess I am not sure which aspects of SerializerFactory configuration you are referring to? No custom factory is used, and although some set methods probably set things on that factory indirectly, I don't see immediate paths.

@SimonCockx
Copy link
Contributor Author

SimonCockx commented Oct 28, 2024

But I guess I am not sure which aspects of SerializerFactory configuration you are referring to? No custom factory is used, and although some set methods probably set things on that factory indirectly, I don't see immediate paths.

Just to clarify the issue: the JacksonXmlModule adds the following two modifiers:

context.addBeanSerializerModifier(new XmlBeanSerializerModifier());
context.addBeanDeserializerModifier(new XmlBeanDeserializerModifier(_cfgNameForTextElement));

When setting the SerializerFactory after this module is registered, these modifiers are lost.

BUT, if you had time to maybe propose a pr, I'd make sure find time to review and help with it.

Thanks. I'll see if I find a moment, but can't make any promise either. :)

@cowtowncoder
Copy link
Member

Ah. Yes, flow of configuration gets bit hairy, since SerializerFactory is amongst oldest extant abstractions and its configuration was not as well-thought-out as newer additions.
This does explain the problem well fwtw.

And yes, pr would be great but we all have limited time so I take whatever I can get. :)

@cowtowncoder
Copy link
Member

I did #680 and I think it might be the best small thing I can do; will merge.

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

No branches or pull requests

2 participants