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

ToXmlGenerator ignores Base64Variant while serializing byte[] #377

Closed
ghenadiibatalski opened this issue Dec 13, 2019 · 6 comments
Closed

Comments

@ghenadiibatalski
Copy link

Hello, i'm using Jackson mapper and dataformat-xml 2.10.0 brought by Spring Boot 2.2.1.

Currently i recognize following problem: byte[] is properly serialized to base64 but in a wrong Base64Variant. I'm expecting the serialization in a default base64variant MIME-NO-LINEFEEDS but this is not the case, regardless, what variant i configure on an ObjectMapper. This because the ToXmlGenerator accepts the parameter b64variant but doesn't propagate it to underlying _xmlWriter (in my case woodstox stax2) which uses by default MIME Base64 Variant.

Could someone please improve this.

Many thanks in advance and kind regards,
Gena

@cowtowncoder
Copy link
Member

Sounds like a reasonable improvement request. I am not sure how easy it would be to do: stax2 API that Woodstox implements does actually have Base64Variant abstraction, as well as pre-defined variants via Base64Variants so it could be straight-forward.

@ghenadiibatalski
Copy link
Author

@cowtowncoder thank you for the quick analyzing the problem! I think, it looks pretty straightforward, to map base64 variants from jackson to stax2. The only thing i'm strumbling over are the some convinience methods. So i could break some important use cases while trying to implement a patch without deeper understanding of the library. Also changing the default Variant of stax2 would be a major breaking change, i think (although for my/default use case helpful)

@cowtowncoder
Copy link
Member

Yes, there can be challenges. Leaving default choice as-is could be doable (by forcing different default for XmlFactory), and overall change should go in 2.11 probably to reduce risk.

@cowtowncoder cowtowncoder added 2.12 and removed 2.11 labels May 13, 2020
@cowtowncoder
Copy link
Member

Starting to work on this, noting that stax2 and jackson default variants align nicely wrt names, but that defaults are different (as already mentioned, so that):

  • Jackson defaults to MIME_NO_LINEFEEDS (since lf-escaping in JSON makes this better)
  • Stax2 defaults to MIME (since linefeeds not problematic with XML)

so the main challenge is just to figure out a way to retain default setting for backwards compatibility, even if it is not quite optimal for XML use case -- users can change defaults for XmlMapper.
One thing that could be considered for 3.0 would be to change this default; I'll consider that after getting first things done first.

@cowtowncoder
Copy link
Member

Oh. Actually looks like Stax2 default of MIME is already used, essentially overriding Jackson-specified default. This would allow keeping the behavior, as long as XmlFactory is configured to force different defaults, which I think should be doable.

@cowtowncoder cowtowncoder changed the title ToXmlGenerator ignores Base64Variant while serializing byte[] ToXmlGenerator ignores Base64Variant while serializing byte[] May 14, 2020
@cowtowncoder
Copy link
Member

Ok. So, this is now implemented, without changing defaults but making it possible to change default to change serialization.

There are couple of potential concerns that may need future work:

  • Custom Base64Variants may be passed but can not really be translated, so it further customizations needed, it may be necessary to add XML-specific overrides so users may pass native Stax2 ByteVariant to use (instead of Jackson's variants that can only map to pre-defined set)
  • Reader side does not use Stax2 typed reads (for a few reasons) and hence actually directly uses Jackson's BaseVariant for decoding. If native Stax2 codecs were to be used on writing, reader-side would need some more thought.
  • I added tests but noticed that special character encoding of "MODIFIED-FOR-URL" is not checked (I don't expect there to be significant issues there, just observation)

Still, I think this is useful improvement over earlier versions: functionality will be included in 2.12(.0).

alex-bel-apica pushed a commit to ApicaSystem/jackson-dataformat-xml that referenced this issue Sep 4, 2020
# Conflicts:
#	release-notes/CREDITS-2.x
#	release-notes/VERSION-2.x
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

2 participants