Incomplete Jackson 2 classpath breaks Grails 8 startup with NoClassDefFoundError in DefaultHttpMessageConverters

[jamesfredley]

Summary

A Grails 8 web application fails to start with NoClassDefFoundError: com/fasterxml/jackson/databind/exc/InvalidDefinitionException as soon as any dependency puts Jackson 2 jackson-core / jackson-annotations on the runtime classpath without Jackson 2 jackson-databind.

Grails 8 ships Jackson 3 for databind (tools.jackson), but the managed platform still supplies Jackson 2 jackson-core, jackson-annotations, and the Jackson 2 dataformat artifacts. When a plugin or library pulls in Jackson 2 core, the resulting classpath has "half of Jackson 2": Spring Framework 7's DefaultHttpMessageConverters.detectMessageConverters() concludes Jackson 2 is available and then hard-references a jackson-databind 2.x class that is not present.

The failure happens while creating OrderedFormContentFilter, so Tomcat never starts and the whole application is dead, regardless of whether the app itself uses Jackson at all.

Found while testing released Grails 7 plugins against 8.0.0-M5.

Grails Version

8.0.0-M5

Java / Groovy Version

Java 21.0.11 (Corretto), Groovy 5.0.8, Spring Boot 4.1.0, Spring Framework 7.0.8

Steps to Reproduce

1. Generate a stock web app with the published 8.0.0-M5 distribution:

grails create-app elasticsearch --profile=web

2. Add a single dependency that transitively brings Jackson 2 core. Any such dependency reproduces it; the one used here is a released Grails 7 plugin:

implementation "org.grails.plugins:grails-elasticsearch:5.1.0"

3. Run gradlew test integrationTest bootJar, or simply boot the app.

Actual Behaviour

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate
  [org.springframework.boot.servlet.filter.OrderedFormContentFilter]:
  Factory method 'formContentFilter' threw exception with message:
  com/fasterxml/jackson/databind/exc/InvalidDefinitionException

Caused by: java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/exc/InvalidDefinitionException
	at org.springframework.http.converter.DefaultHttpMessageConverters$DefaultBuilder.detectMessageConverters(DefaultHttpMessageConverters.java:334)
	at org.springframework.http.converter.DefaultHttpMessageConverters$DefaultClientBuilder.build(DefaultHttpMessageConverters.java:468)
	at org.springframework.http.converter.support.AllEncompassingFormHttpMessageConverter.<init>(AllEncompassingFormHttpMessageConverter.java:42)
	at org.springframework.web.filter.FormContentFilter.<init>(FormContentFilter.java:61)
	at org.springframework.boot.servlet.filter.OrderedFormContentFilter.<init>(OrderedFormContentFilter.java:29)
	at org.springframework.boot.webmvc.autoconfigure.WebMvcAutoConfiguration.formContentFilter(WebMvcAutoConfiguration.java:189)

Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.databind.exc.InvalidDefinitionException

Wrapped in WebServerException from TomcatWebServer.initialize, so the context never refreshes.

Root cause evidence

Contents of BOOT-INF/lib in the built bootJar - note Jackson 2 core and annotations are present, Jackson 3 databind is present, and Jackson 2 databind is missing:

BOOT-INF/lib/jackson-core-2.21.5.jar
BOOT-INF/lib/jackson-annotations-2.21.jar
BOOT-INF/lib/jackson-dataformat-cbor-2.21.4.jar
BOOT-INF/lib/jackson-dataformat-smile-2.21.4.jar
BOOT-INF/lib/jackson-dataformat-yaml-2.21.4.jar
BOOT-INF/lib/jackson-databind-3.1.5.jar
BOOT-INF/lib/jackson-core-3.1.5.jar
BOOT-INF/lib/spring-boot-jackson-4.1.0.jar

dependencyInsight shows the Jackson 2 core arriving transitively and being upgraded by the managed platform:

com.fasterxml.jackson.core:jackson-core:2.14.2 -> 2.21.5
\--- org.elasticsearch:elasticsearch-x-content:7.17.29
     \--- org.elasticsearch:elasticsearch:7.17.29
          \--- org.grails.plugins:grails-elasticsearch:5.1.0

com.fasterxml.jackson.core:jackson-core:2.21.4 -> 2.21.5
\--- org.springframework.boot:spring-boot-dependencies:4.1.0

Confirmation of the diagnosis

Adding the missing Jackson 2 databind to the same app:

runtimeOnly "com.fasterxml.jackson.core:jackson-databind:2.21.5"

makes the startup crash disappear entirely. The app then boots, the plugin wires up, and the only remaining failure is the plugin's own ConnectException reaching an Elasticsearch server - an unrelated, expected environmental error:

Caused by: org.elasticsearch.ElasticsearchException at RestHighLevelClient.java:2695
    Caused by: java.util.concurrent.ExecutionException at BaseFuture.java:257
        Caused by: java.net.ConnectException at Net.java:694

So the startup failure is purely the incomplete Jackson 2 classpath, not the plugin's behaviour.

Expected Behaviour

Either the managed platform keeps Jackson 2 internally consistent (if Jackson 2 jackson-core / jackson-annotations are managed and can reach the runtime classpath, Jackson 2 jackson-databind should be managed and present too), or Jackson 2 artifacts should not be able to reach the application runtime classpath at all, so Spring's Jackson 2 detection never triggers.

Right now a user gets a hard, non-obvious startup crash in an unrelated filter, with nothing pointing at the actual cause.

Impact

This is not specific to one plugin. Any Grails 7 plugin or third-party library that brings Jackson 2 core without databind - a very common shape, since many libraries depend on jackson-core or a Jackson 2 dataformat only - will take down a Grails 8 application at startup. The error message names neither Grails nor the offending dependency.

Suggested resolution

Options for discussion:

1. Manage com.fasterxml.jackson.core:jackson-databind (2.x) in the Grails platform alongside the Jackson 2 jackson-core / jackson-annotations / dataformat entries so the Jackson 2 classpath is never half-present.
2. Alternatively, keep Jackson 2 fully off the application runtime classpath and let Jackson 3 be the only Jackson present.
3. At minimum, document this failure mode and the runtimeOnly "com.fasterxml.jackson.core:jackson-databind:<2.x>" workaround in the Grails 8 upgrade guide's Jackson section, since the stack trace gives no hint.

Notes

Part of a compatibility sweep of released Grails 7 plugins against 8.0.0-M5. Related plugin-compatibility issues found in the same sweep: #16122 and #16123. Existing compatibility-shim precedents: #16011 and #16101.

[jamesfredley]

Follow-up: why jackson-databind 2 disappears, and how common this is

I resolved the runtime graphs of 13 released Grails plugins against org.apache.grails:grails-bom:8.0.0-M5 to see how widespread this is, and to pin down why the Jackson 2 classpath ends up half-present. The result narrows the problem usefully.

It is specifically a partial Jackson 2 that breaks

Plugins that bring the complete Jackson 2 stack are fine, because Spring's detection then finds the databind classes it expects:

Plugin	Jackson 2 artifacts pulled	Verdict
org.grails.plugins:grails-elasticsearch:5.1.0	jackson-core, jackson-dataformat-cbor/smile/yaml - no databind	AT RISK
org.grails.plugins:grails-cache-redis:6.0.0-RC1	jackson-core, jackson-annotations, jackson-databind, jackson-datatype-jdk8, jackson-datatype-jsr310	OK
org.grails.plugins:sitemesh2:6.2.4	same complete set including jackson-databind	OK
audit-logging:6.0.0, grails-web-console:7.1.0, grails-logical-delete:3.0.0, grails-shiro:6.0.0, cache-ehcache:5.0.0-RC1, grails-mail:5.0.3, grails-export:7.1.0, grails-quartz:4.0.1, grails-redis:5.0.1, neo4j:8.1.0	none	OK

So the trigger is narrow: a dependency that pulls Jackson 2 core and/or dataformats while nothing supplies Jackson 2 databind.

Where the databind dependency goes

The same plugin resolved without the Grails BOM does include Jackson 2 databind:

=== ELASTICSEARCH WITHOUT GRAILS BOM ===
    com.fasterxml.jackson.core:jackson-core:2.21.3
    com.fasterxml.jackson.core:jackson-databind:2.21.3
    com.fasterxml.jackson.core:jackson-annotations:2.21
    com.fasterxml.jackson.dataformat:jackson-dataformat-smile:2.21.3
    com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.21.3
    com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:2.21.3
    com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.21.3

With the 8.0.0-M5 BOM applied, jackson-databind 2 is gone entirely - dependencyInsight reports No dependencies matching given input were found in configuration ':scan_elasticsearch'.

This is not a BOM exclusion. grails-base-bom-8.0.0-M5.pom still manages it:

<jackson2.version>2.21.5</jackson2.version>
<jackson3.version>3.1.5</jackson3.version>
...
<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>${jackson2.version}</version>
</dependency>

The cause is that the only path to Jackson 2 databind was the plugin's Grails 7 dependencies. The plugin requests org.apache.grails:*:7.0.11, and the Grails 8 BOM upgrades those to 8.0.0-M5, which moved to Jackson 3 (tools.jackson). Upgrading them removes the edge that used to supply Jackson 2 databind.

Meanwhile the non-Grails transitives are untouched. org.elasticsearch:elasticsearch-x-content:7.17.29 depends on jackson-core and the three dataformats but not on databind:

+--- com.fasterxml.jackson.core:jackson-core:2.14.2 -> 2.21.5
+--- com.fasterxml.jackson.dataformat:jackson-dataformat-smile:2.14.2 -> 2.21.4
+--- com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.14.2 -> 2.21.4
\--- com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:2.14.2 -> 2.21.4

Those survive the BOM upgrade, so the app is left with Jackson 2 core plus dataformats and no Jackson 2 databind - exactly the state Spring Framework 7 mishandles.

Why this generalises

Any Grails 7 plugin in this shape hits it:

1. it depends on Grails 7 artifacts (so it inherited Jackson 2 databind transitively), and
2. it also depends on a non-Grails library that pulls Jackson 2 core or a Jackson 2 dataformat directly.

Condition 1 is true of essentially every Grails 7 plugin. Condition 2 is common for anything wrapping a client library - Elasticsearch, Kafka, AWS SDKs, CBOR/Smile/YAML users. The plugin author does nothing wrong and nothing in their build changes; the classpath simply becomes inconsistent when the Grails BOM upgrades the Grails half to Jackson 3.

That also means the sample above understates it - it only counts plugins I resolved, and any app dependency (not just a plugin) in shape 2 does the same thing.

Bearing on the fix

Since the BOM already manages com.fasterxml.jackson.core:jackson-databind:2.21.5, the smallest fix may be to ensure Jackson 2 databind is present whenever Jackson 2 core is on the runtime classpath, rather than merely version-managed. Otherwise the failure stays silent until Tomcat start, and the stack trace names neither Grails nor the dependency responsible.

[jamesfredley]

Correction and a minimal reproduction with no plugin involved

I stated above that this affects "any dependency bringing Jackson 2 core without databind". That was too broad - I had only demonstrated it through the Elasticsearch plugin. I bisected it in a stock 8.0.0-M5 app and the real trigger is narrower and more specific.

Bisection results

Stock grails create-app --profile=web on 8.0.0-M5, adding only the listed dependencies, asserting nothing more than that the application context starts:

Added to a stock app	Result
com.fasterxml.jackson.core:jackson-core:2.21.5	starts fine
jackson-core:2.21.5 + jackson-annotations:2.21	starts fine
a single Jackson 2 dataformat with jackson-databind excluded	fails to start

So Jackson 2 jackson-core, with or without jackson-annotations, is harmless. The trigger is a Jackson 2 dataformat artifact present while Jackson 2 jackson-databind is absent.

Minimal reproduction

This is the whole thing - no plugin, three lines in a stock app:

implementation("com.fasterxml.jackson.dataformat:jackson-dataformat-smile:2.21.4") {
    exclude group: 'com.fasterxml.jackson.core', module: 'jackson-databind'
}

BootSpec > the application context starts FAILED
    Caused by: org.springframework.boot.web.server.WebServerException at TomcatWebServer.java:150
        Caused by: java.lang.NoClassDefFoundError at DefaultHttpMessageConverters.java:334
            Caused by: java.lang.ClassNotFoundException at BuiltinClassLoader.java:641

jackson-dataformat-cbor and jackson-dataformat-yaml behave the same way; I originally hit all three together via Elasticsearch.

This makes sense mechanically: Spring's DefaultHttpMessageConverters.detectMessageConverters() sees the Smile/CBOR/YAML dataformat classes, concludes Jackson 2 support is available, and then builds a Jackson 2 converter that hard-references a jackson-databind class.

How the databind gap arises in practice

The explicit exclude above is just the shortest way to force the state. In a real build it happens two ways:

1. A library excludes databind itself. org.elasticsearch:elasticsearch-x-content depends on jackson-core and the three dataformats without pulling databind, which is how the original report arose.
2. The BOM upgrade removes the only databind path, as described in my previous comment: the plugin's Grails 7 dependencies supplied Jackson 2 databind, and upgrading them to 8.0.0-M5 (Jackson 3) deletes that edge while the dataformats survive.

Revised impact

Narrower than I first said, but still not rare, and worth keeping:

• It needs a Jackson 2 dataformat, not merely Jackson 2 core. CBOR, Smile, YAML, and presumably XML are common in client libraries (Elasticsearch, Kafka, various AWS and protobuf-adjacent stacks).
• It is not plugin-specific - the reproduction above has no Grails plugin at all, which was the part of my original claim that does hold.
• The failure is still total (Tomcat never starts) and still points at OrderedFormContentFilter rather than at the responsible dependency.

Apologies for the imprecision in the original write-up; the bisected trigger above should be the one to design against.

[jamesfredley]

Verified per-dataformat matrix (and one more correction)

I tested each Jackson 2 dataformat individually in a stock 8.0.0-M5 app rather than leaving my earlier statements as inference. Two things changed.

Each row is a stock grails create-app --profile=web with only that one dependency added, jackson-databind excluded, asserting only that the application context starts:

Dependency added	Result	Failure site
jackson-dataformat-smile:2.21.4	fails to start	DefaultHttpMessageConverters.java:334
jackson-dataformat-cbor:2.21.4	fails to start	DefaultHttpMessageConverters.java:353
jackson-dataformat-yaml:2.21.4	fails to start	DefaultHttpMessageConverters.java:362
jackson-dataformat-xml:2.21.4	starts fine	-
jackson-core:2.21.5	starts fine	-
jackson-core + jackson-annotations	starts fine	-

Correction

I wrote "and presumably XML" in my previous comment. That is wrong - jackson-dataformat-xml does not trigger this and the app starts normally. The confirmed trigger set is Smile, CBOR, and YAML.

The more interesting detail

The three failures occur at three different lines of DefaultHttpMessageConverters.detectMessageConverters() - 334, 353, and 362. These are separate detection branches, one per dataformat, and each independently reaches a jackson-databind class without first confirming databind is present. It is not one missing guard but the same omission repeated across several branches, which is worth knowing if the fix is pursued on the Spring side rather than the BOM side.

jackson-dataformat-xml presumably guards differently or requires databind through another path, which is why it survives.

Net effect on this issue

The trigger is now pinned precisely:

• Breaks startup: Jackson 2 jackson-dataformat-smile, -cbor, or -yaml on the runtime classpath while Jackson 2 jackson-databind is absent.
• Harmless: Jackson 2 jackson-core, jackson-annotations, jackson-dataformat-xml.

Elasticsearch pulls smile, cbor, and yaml, which is why it hit this so hard.