Tolerate JAX-RS 2.2 in jackson-module-jaxb-annotations so that it can be deployed in Liberty alongside features which use 2.2
Closed this issue · 8 comments
When using a Liberty container image such as icr.io/appcafe/websphere-liberty:23.0.0.9-full-java11-openj9-ubi and trying to use the jackson-module-jaxb-annotations-2.16.0.jar we get a conflict due to two implementations of javax.xml.bind being available.
The features we need to use within Liberty only supply the 2.2 implementation.
Looking at jackson-module-jaxb-annotations-2.16.0.jar we can see it has compile dependencies on jakarta.xml.bind-api 2.3.2 and so provides an implementation at 2.3. This then causes the conflict.
This issue is to request that jaxb annotations be updated in some way to change the toleration that ends up in the /META-INF/MANIFEST.MF file in the Import-Package section to be:
javax.xml.bind;version="[2.2,3)",javax.xml.bind.annotation;
version="[2.2,3)",javax.xml.bind.annotation.adapters;version="[2.2,3)
Instead of what is currently has:
javax.xml.bind;version="[2.3,3)",javax.xml.bind.annotation;
version="[2.3,3)",javax.xml.bind.annotation.adapters;version="[2.3,3)
Thanks
Two sections you show seem to be identical? Also, not sure how JAX-RS is related here (Jackson does have JAX-RS/Jakarta-RS providers but those are separate from modules here).
But one thing to note is that there are 2 modules: jackson-module-jaxb-annotations is older one for pre-Jakarta (JAXB) annotations; newer jackson-module-jakarta-xmlbind-annotations for Jakarta variant.
Would it be that you want the latter, not former?
Hi @cowtowncoder there is a tiny difference in the code blocks. The [min,max) version toleration changes between the two. Today the jaxb modules tolerate [2.3,3) but we are looking for them to tolerate [2.2,3) as our Liberty application server does not support 2.3.
Ah! Easy to miss.
So, I'd be open for a PR although slightly worried whether it might cause issues for other users. But I guess as long as whatever is including module specifies 2.3 or later as dependency, it should not become problematic.
So, PR against 2.16 would be welcome (I know it's easy enough and I could do but it's still slightly easier to get a PR to review and merge).
Hi @cowtowncoder I raised a PR at the 2.17 level, as we frequently update to latest version so would be looking to have this in future releases as well. I wasn't sure if having the PR at 2.16 meant it wouldn't go in subsequent releases. I can PR again at 2.16 if that is preferable.
@JDUNNIN I always merge forward, so 2.16 would indeed be rolled to 2.17 and then master (3.0).
With the exception that if the change is to pom.xml it needs manual merging (which I will take care of).
So 2.16 would be preferable.
@cowtowncoder I've recreated the PR at 2.16 👍 Thanks
Hi,
I don't think that the fix of this issue did what was supposed to do.
Version 2.17.x:
Version 2.18.x:
It breaks our tests :-(
Ok I suppose PR to rectify the situation would then be needed. But I'll be damned if I know what is the proper thing to do any more :-(
Change here was meant to affect OSGi settings but I guess unintended side-effect is with regular Maven dependency.