java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/util/Separators$Spacing v7.0.0

[joepaquette]

Describe the bug ***** Original error stack: com/fasterxml/jackson/core/util/Separators$Spacing java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/util/Separators$Spacing at ca.uhn.fhir.parser.json.jackson.JacksonWriter.init(JacksonWriter.java:48) at ca.uhn.fhir.parser.JsonParser.doEncodeResourceToJsonLikeWriter(JsonParser.java:212) at ca.uhn.fhir.parser.JsonParser.doEncodeResourceToWriter(JsonParser.java:223) at ca.uhn.fhir.parser.BaseParser.encodeResourceToWriter(BaseParser.java:345) at ca.uhn.fhir.parser.BaseParser.encodeResourceToWriter(BaseParser.java:302) at ca.uhn.fhir.parser.BaseParser.encodeResourceToString(BaseParser.java:290) ... Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.core.util.Separators$Spacing at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) ... 92 more

To Reproduce Verify HAPI FHIR is v7.0.0 and com.fasterxml.jackson.core:jackson-core is v2.15.3 for failing test. Override com.fasterxml.jackson.core:jackson-core at v2.16.1 for passing test. Unit test to demonstrate:

  @Test
  @DisplayName("Verify work around for HAPI FHIR bug")
  void testForHapiFhirParserBug() {
    Basic basicResource = new Basic();
    basicResource.setId("testFhirId");
    IParser parser = FhirContext.forR4().newJsonParser().setPrettyPrint(true);
    try {
      String encodedResource = parser.encodeResourceToString(basicResource);
      assertNotNull(encodedResource);
    } catch (NoClassDefFoundError e) {
      StackTraceElement[] stackTrace = e.getStackTrace();
      String msg = String.format(
        "Work around for HAPI FHIR bug failed! Error message: %s; Error source: %s",
        e.getMessage(),
        stackTrace[0]
      );
      fail(msg);
    }
  }

Expected behavior java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/util/Separators$Spacing does not get thrown

Screenshots N/A

Environment (please complete the following information):

• HAPI FHIR Version: 7.0.0
• OS: Windows WSL 2:
  • Distributor ID: Ubuntu
  • Description: Ubuntu 20.04.6 LTS
  • Release: 20.04
  • Codename: focal
• Browser: N/A

Additional context

• HAPI FHIR bug: NoClassDefFound com/fasterxml/jackson/core/util/Separators$Spacing
• HAPI FHIR v7.0.0 uses Spring Boot v3.2.0 which inherits dependency management from 'spring-boot-dependencies'.
• Refer to https://docs.spring.io/spring-boot/docs/3.2.0/reference/html/dependency-versions.html which shows that com.fasterxml.jackson.core:jackson-core is v2.15.3.
• Error thrown:
  • java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/util/Separators$Spacing
  • Error source: at ca.uhn.fhir.parser.json.jackson.JacksonWriter.init(JacksonWriter.java:48)
• Bug is that com/fasterxml/jackson/core/util/Separators$Spacing was added starting in v2.16.
• Work around is to override dependency com.fasterxml.jackson.core:jackson-core to v2.16.1.

[XcrigX]

I'm hitting this as well. It really plays (dependency) hell on downstream projects when the HAPI libs break from the SpringBoot managed dependency versions, IMO.

As of the current SB version in HAPI (3.2.0), Jackson is at 2.15.3: https://docs.spring.io/spring-boot/docs/3.2.0/reference/html/dependency-versions.html

I would highly encourage the HAPI team to use the SpringBoot BOM and stick to the versions there except in rare cases.

[jamesagnew]

I don't know that using a managed version of Jackson is an option - that library has a surprising number of cves and we regularly seem to need to manually bump it... Also, boot is not a requirement outside of the jpa starter project.

A pr to address this would be gladly accepted tho. sent from my phone.

On Mon, Jun 17, 2024, 15:24 craig mcclendon @.***> wrote:

I'm hitting this as well. It really plays (dependency) hell on downstream projects when the HAPI libs break from the SpringBoot managed dependency versions, IMO.

As of the current SB version in HAPI (3.2.0), Jackson is at 2.15.3:

https://docs.spring.io/spring-boot/docs/3.2.0/reference/html/dependency-versions.html

I would highly encourage the HAPI team to use the SpringBoot BOM and stick to the versions there except in rare cases.

— Reply to this email directly, view it on GitHub https://github.com/hapifhir/hapi-fhir/issues/5736#issuecomment-2174253761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2N7HK76RCLRCWLXWOYQKTZH4ZYLAVCNFSM6AAAAABDX6DJSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZUGI2TGNZWGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[XcrigX]

Thanks @jamesagnew - you don't necessarily need a dependency on SpringBoot in any of the modules that don't require it- but you could still import the Springboot BOM in the dependency management section of the HAPI parent/BOM and then use default versions from SB for common dependencies. It doesn't solve ALL problems, but at least all the dependencies are tested with the SB ecosystem for compatibility with a given version of Spring/SpringBoot.

Anecdotally for this case, many of my projects use the SpringBoot starter parent, and then import HAPI libs (FHIR-enabled RESTful services, etc.). In this particular case today, I manually updated Jackson to match HAPI, but then got this:

Caused by: com.fasterxml.jackson.databind.JsonMappingException: Scala module 2.15.3 requires Jackson Databind version >= 2.15.0 and < 2.16.0 - Found jackson-databind version 2.16.0
	at com.fasterxml.jackson.module.scala.JacksonModule.setupModule(JacksonModule.scala:61)
	at com.fasterxml.jackson.module.scala.JacksonModule.setupModule$(JacksonModule.scala:46)
	at com.fasterxml.jackson.module.scala.DefaultScalaModule.setupModule(DefaultScalaModule.scala:17)
	at com.fasterxml.jackson.databind.ObjectMapper.registerModule(ObjectMapper.java:906)
	at com.fasterxml.jackson.databind.ObjectMapper.registerModules(ObjectMapper.java:1108)
	at com.fasterxml.jackson.databind.ObjectMapper.findAndRegisterModules(ObjectMapper.java:1192)
	at org.hibernate.type.format.jackson.JacksonJsonFormatMapper.<init>(JacksonJsonFormatMapper.java:26)
	at org.hibernate.type.format.jackson.JacksonIntegration.<clinit>(JacksonIntegration.java:18)
	... 110 common frames omitted

.. Ugh.. haven't gotten far enough with the above error to see if I can work around it.

A couple of months ago is was an older Spring Security dependency that was hardcoded in the CR module. So then I have to go play dependency management games to track down the offending library, move things around in the POM or overwrite a version or exclude a transitive dependency, etc. It seems like it might be easier on HAPI users and Smile to offload a lot of the dependency version management to Spring.

I hear what you're saying about open CVEs, and sometimes updating something can't be avoided. But Spring is usually pretty sensitive to open CVEs given so many production workloads use it, so most of the time a fix is available or around the corner by simply updating the Spring/boot versions.

Anyway, JMO.
Cheers.