Incompatible woodstox-core and stax2-api dependencies

[wilkinsona]

2.9.9 upgraded to woodstox-core 5.1 which depends on stax2-api 4.1 but it still depends directly on stax2-api 3.1.4. As a result, when using Maven, a dependency on jackson-dataformat-xml results in an incompatible combination of versions of woodstox-core and stax2-api and a NoSuchMethodError results when also using Hibernate:

…
Caused by: java.lang.NoSuchMethodError: org.codehaus.stax2.ri.SingletonIterator.create(Ljava/lang/Object;)Lorg/codehaus/stax2/ri/SingletonIterator;
	at com.ctc.wstx.util.DataUtil.singletonIterator(DataUtil.java:41)
	at com.ctc.wstx.evt.CompactStartElement.getAttributes(CompactStartElement.java:100)
	at org.hibernate.boot.jaxb.internal.stax.JpaOrmXmlEventReader.existingXmlAttributesIterator(JpaOrmXmlEventReader.java:112)
	at org.hibernate.boot.jaxb.internal.stax.JpaOrmXmlEventReader.mapAttributes(JpaOrmXmlEventReader.java:100)
	at org.hibernate.boot.jaxb.internal.stax.JpaOrmXmlEventReader.wrap(JpaOrmXmlEventReader.java:84)
	at org.hibernate.boot.jaxb.internal.stax.JpaOrmXmlEventReader.wrap(JpaOrmXmlEventReader.java:74)
	at org.hibernate.boot.jaxb.internal.stax.JpaOrmXmlEventReader.peek(JpaOrmXmlEventReader.java:63)
	at org.dom4j.io.STAXEventReader.readElement(STAXEventReader.java:315)
	at org.dom4j.io.STAXEventReader.readNode(STAXEventReader.java:198)
	at org.hibernate.boot.jaxb.internal.MappingBinder$1.readNode(MappingBinder.java:104)
	at org.dom4j.io.STAXEventReader.readDocument(STAXEventReader.java:275)
	at org.hibernate.boot.jaxb.internal.MappingBinder.toDom4jDocument(MappingBinder.java:108)
	at org.hibernate.boot.jaxb.internal.MappingBinder.doBind(MappingBinder.java:71)
	at org.hibernate.boot.jaxb.internal.AbstractBinder.doBind(AbstractBinder.java:102)
	at org.hibernate.boot.jaxb.internal.AbstractBinder.bind(AbstractBinder.java:57)
	at org.hibernate.boot.jaxb.internal.InputStreamXmlSource.doBind(InputStreamXmlSource.java:43)
	at org.hibernate.boot.jaxb.internal.InputStreamXmlSource.doBind(InputStreamXmlSource.java:38)
	at org.hibernate.boot.spi.XmlMappingBinderAccess.bind(XmlMappingBinderAccess.java:79)
	at org.hibernate.boot.model.process.internal.ScanningCoordinator.applyScanResultsToManagedResources(ScanningCoordinator.java:220)
	at org.hibernate.boot.model.process.internal.ScanningCoordinator.coordinateScan(ScanningCoordinator.java:82)
	at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.prepare(MetadataBuildingProcess.java:98)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:234)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:167)
	at org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:51)
	at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:390)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:377)
	at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.afterPropertiesSet(LocalContainerEntityManagerFactoryBean.java:341)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1842)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1779)
	... 72 more

[wilkinsona]

The knock-on effect of a maintenance release of Jackson requiring a new minor release of woodstox-core which, in turn, requires a new major release of stax2-api is a bit nasty. From a compatibility perspective, I think it might be preferable for Jackson 2.9.x to stick with Woodstox 5.0.x.

[cowtowncoder]

Ouch. Yes, this is unfortunate. Wish I had caught that before. Thank you for reporting this.

Unfortunately the way Maven releases work, I am not sure much that can be done to help here.
I can upgrade stax2-api dependency for 2.9, but that (or downgrade if that was done) would only go in 2.9.10 and I don't think that will get released in near future.

[wilkinsona]

Thanks, @cowtowncoder. I discovered this in the context of Spring Boot where we have some dependency management that gives us a chance to adjust the versions without requiring a new release of Jackson.

Is downgrading Woodstox to 5.0.x a viable option for use with jackson-dataformat-xml 2.9.9? The upgrade commit suggests that it'll work but there may, of course, have been subsequent changes that require 5.1.

Alternatively, we could use our dependency management to upgrade stax2-api to 4.1, but the jump to a new major version makes me a bit nervous. There are other projects in the ecosystem, such as SolrJ and, as you know, woodstox-core-asl that currently use 3.1.4. Is stax2-api 4.1 backwards compatible with 3.1?

[dadoonet]

FYI after upgrading to 2.9.9, my project is now complaining because it's checking transitive dependencies:

[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (enforce) @ fscrawler-framework ---
[WARNING] 
Dependency convergence error for org.codehaus.woodstox:stax2-api:3.1.4 paths to dependency are:
+-fr.pilato.elasticsearch.crawler:fscrawler-framework:2.7-SNAPSHOT
  +-com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.9.9
    +-org.codehaus.woodstox:stax2-api:3.1.4
and
+-fr.pilato.elasticsearch.crawler:fscrawler-framework:2.7-SNAPSHOT
  +-com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.9.9
    +-com.fasterxml.woodstox:woodstox-core:5.1.0
      +-org.codehaus.woodstox:stax2-api:4.1

[WARNING] Rule 1: org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:

@cowtowncoder What about using maven-enforcer-plugin with a dependencyConvergence rule which would hopefully detect this? Example here: https://github.com/dadoonet/fscrawler/blob/master/pom.xml#L305-L328

[cowtowncoder]

@dadoonet I am not opposed to enforcer plugin, although I thought it was already enabled for Jackson.

Further on upgrade: I did not realize (... despite being author of Woodstox :) ) that there was such a jump for stax2-api. Would have only upgraded for 2.10.

[cowtowncoder]

@wilkinsona Yes, downgrade should be fine as far as I know. Alternatively I would think that upgrade of stax2-api to 4.x ought to be ok since despite it being major version jump, there is no fundamental major refactoring or incompatibility. Rather change was to align with Woodstox 5.0, although somewhat ironically I did not (alas) upgrade Woodstox 5.0 use it (facepalm).

So. I think that as long as you align woodstox-core and stax2-api, external API used by everything outside should be stable and compatible.

[wilkinsona]

Thank you, @cowtowncoder, that's very helpful.

[usulkies]

Temporary workaround:
use mvn dependency:tree to make sure Jackson-dataformat-xml is the only user of the stax2-api
After assuring that, add this to dependency management section in your pom.xml:

<dependency> <!-- Workaround for jackson-dataformat-xml issue #340 of forgetting to update stax2-api  -->  
  <groupId>org.codehaus.woodstox</groupId>  
  <artifactId>stax2-api</artifactId>  
  <version>4.1</version>  
</dependency>

[cowtowncoder]

I wonder if this is something that actually belongs in jackson-bom for version alignment purposes.

[wilkinsona]

FWIW, my opinion is that it does not. The bom is for Jackson so it should only manage the versions of Jackson's own modules and not of its dependencies.

[cowtowncoder]

Fair enough. It seems like bit of borderline case where it might help, but since use for XML (f.ex) is only from xml format module and JAX-RS xml provider, there isn't that much benefit even if it was added. Same goes for JAXB api.