Azure-sdk-for-java: Make jackson-databinding-xml dependency optional

Created on 24 Jan 2020  路  17Comments  路  Source: Azure/azure-sdk-for-java

We recently upgraded Azure-spring-boot-starter from 2.2.1 to 2.2.2

It led to various issues because this bugfix upgrade induced the drop of azure-keyvault dependency to azure-security-keyvault-secrets, which depends on azure-core, which depends on jackson-databinding-xml.

This led to various dubious side-effects like Spring RestTemplate switching from JaxB MessageSerializer to JacksonXml (see the static initializer in RestTemplate), which induces XML as default protocol (over json) when POSTing a Map with a RestTemplate, without specifing any Content-Type, which naturally led the many things not working anymore in our app.

However, exlcuding spring-databinding-xml from our dependencies prevent JacksonAdapter class to be initialized, while the XmlAdapter seems not to be strictly necessary.

Would it be reasonnable to make JacksonAdapter dependency over XmlAdapter an option, just like RestTemplate uses XmlAdapter only if it is available?

Thanks

Azure.Core Client customer-reported feature-request

Most helpful comment

Hi @chenrujun,

Currently, azure-core is required to have jackson-databind-xml as it handles serialization work for most other Azure SDKs which build on top of it. Given that some services use XML it is required to have this dependency.

In an upcoming change I'm looking into decentralizing serialization handling to allow down stream SDKs more flexibility. While doing this I can look at whether it would be possible to remove this dependency without it being backwards compatibility breaking.

All 17 comments

Thanks for reporting this issue @blacelle. @hemanttanwar can you please follow up?

@joshfree @hemanttanwar Have you been able to dig into this? Thanks

Now azure-core does not have dependency of jackson-databinding-xml, does it mean this problem have been solved?

@chenrujun Can this be updated in dependencies like azure-identity (that make use of azure-core)? We are using version 1.1.0-beta.6 at this moment, and would not like to make use of the xml dependency too (as it changes our Controller's default JSON response type to XML).
Can we simply exclude it from azure-identity without any problem?

@amusaafir ,

Can this be updated in dependencies like azure-identity

Now azure-identity does not have dependency of jackson-databinding-xml.

Actually, we do not have dependency of jackson-databinding-xml in the whole repo

@chenjianfei2017 Thanks for the quick reply. My bad, I meant jackson-dataformat-xml which is included by azure-core, and which is subsequently used by azure-identity. (I think it's better if I open a new issue regarding this, as it is a different dependency than the one mentioned in this issue)

@amusaafir ,

Thank you for your quick response.

Can you use exclusions in you pom to exclude that dependency?

@chenrujun That does work, indeed - would it have any unexpected side effects?

Thank you :)

Edit: this does seem to break the application after all (during the retrieval of secrets).

would it have any unexpected side effects?

I'm not sure. I'm the developer about spring-starter. I'm not very familiar with azure-core.

@alzimmermsft , I see you committed in azure-cure, could you please check this issue?

Hi @chenrujun,

Currently, azure-core is required to have jackson-databind-xml as it handles serialization work for most other Azure SDKs which build on top of it. Given that some services use XML it is required to have this dependency.

In an upcoming change I'm looking into decentralizing serialization handling to allow down stream SDKs more flexibility. While doing this I can look at whether it would be possible to remove this dependency without it being backwards compatibility breaking.

@alzimmermsft - Do you have an update? This one is 207 days old, so we'd like to close out soon. Thanks, Jon

From reviewing how XmlMapper is leveraged in Azure Core it won't be possible to remove it without leading to functional breaking changes for backwards compatibility. However, it should be possible to shade and relocate the jackson-dataformat-xml dependency so that RestTemplate no longer picks it up on the classpath.

I think I'm having related issues #15486

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

@alzimmermsft Have you validated the shade+relocate option?

I attempted to validate @blacelle and I see the issue is that since the Jackson XML dependency is a dependency's dependency (application -> azure-core -> Jackson XML) it is not possible to resolve the issue through shading. Through additional research I see that RestTemplate uses well-known HttpMessageConverters when checking the class path for automatic converters. Replacing the Jackson XML (MappingJackson2XmlHttpMessageConverter) HttpMessageConverter with the JAXB (Jaxb2RootElementHttpMessageConverter) HttpMessageConverter using RestTemplate's get and set converter APIs should resolve the issue. If Spring also offers a way to pre-configure all RestTemplate instances that should simplify the fix further.

Hi @alzimmermsft addressing your proposal I implemented the custom MessageConverter List inside a WebMvcConfigurer by using only MappingJackson2HttpMessageConverter and Jaxb2RootElementHttpMessageConverter. As a result, the default protocol (JSON) for web services through RestController is not overridden with XML and the integration with the Azure SDK (in my case blob storage), which uses XML, is working fine.

Was this page helpful?
0 / 5 - 0 ratings