[FEATURE REQ] Allow customising the XmlFactory passed in JacksonAdapter for Azure Storage

[timja]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

In an application where the current Threads context class loader is not the main class loader I am unable to load the required stax implementation required by jackson-xml-databind. The one bundled in the JDK is incompatible.

In normal situations I would pass by expected classloader down to whatever is doing the classloading, unfortunately jackson-databind-xml doesn't expose a method for that although the JDK does, jackson-constructor

It does provide constructors for an already configured XmlFactory, if I could pass that to the JacksonAdapter in some way then that would solve my problem, (would be passed to the builder instead of it creating one) https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/core/azure-core/src/main/java/com/azure/core/util/serializer/JacksonAdapter.java#L137

Describe the solution you'd like
A supported API for providing either my classloader for loading the XMLInputFactory or providing a precreated XmlFactory

Describe alternatives you've considered

• There's work in progress to try hack this by setting the thread context classloader, but it's brittle work and leads to very ugly code, Work around class loading issue jenkinsci/azure-storage-plugin#195

• Allowing me to pass a custom classloader would be better all round, I've raised a PR to jackson to see if they'll take that PR: Add classloader parameter to XmlFactory FasterXML/jackson-dataformat-xml#480

Additional context
Add any other context or screenshots about the feature request here.

jenkinsci/jackson2-api-plugin#82 (comment)
jenkinsci/azure-storage-plugin#194
jenkinsci/azure-storage-plugin#188

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Description Added
• Expected solution specified

[timja]

This has been worked around upstream in FasterXML/jackson-dataformat-xml#482.

Having said that the maintainer of jackson of jackson said:

downstream frameworks may want to explicitly construct and pass XMLInputFactory and XMLOutputFactory, going forward. That won't solve all issues but may help avoid one error mode.

That would allow a consistent implementation being used (Woodstox or Aalto), instead of our case now with the JDK implementation being picked up.

FasterXML/jackson-dataformat-xml#480 (comment)

Any thoughts?

[rickle-msft]

@alzimmermsft This sounds like a policy that should be standardized across sdks. Any thoughts on if this is something that can go through the arch board?

[timja]

Further discussion in FasterXML/jackson-dataformat-xml#483, which likely means no change is required here, although that doesn't prevent the Azure SDK from explicitly configuring the correct stax implementation.

[alzimmermsft]

@timja is this issue still a problem? I see that Jackson ended up making a change with how this is loaded, did that solve your problem?

[timja]

For my purpose it works, but it’s recommended to allow users to configure the classloader themselves

[github-actions]

Hi @timja, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.