|
| 1 | +# Jackson 2.18 – `joda.time.DateTime` Deserialization Regression |
| 2 | + |
| 3 | +## Symptom |
| 4 | + |
| 5 | +After upgrading Jackson from **2.15.4 → 2.18.6**, deserializing `joda.time.DateTime` throws: |
| 6 | + |
| 7 | +``` |
| 8 | +com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.exc.MismatchedInputException: |
| 9 | +Cannot construct instance of `org.joda.time.DateTime` (although at least one Creator exists): |
| 10 | +no String-argument constructor/factory method to deserialize from String value ('2016-01-01T23:59:59.000+0000') |
| 11 | +``` |
| 12 | + |
| 13 | +Reproduced by: `EventLoaderTest.testLoadCodeCommitEvent` — `CodeCommitEvent.Record.eventTime` is of type `org.joda.time.DateTime`. |
| 14 | + |
| 15 | +## Root Cause |
| 16 | + |
| 17 | +### Background: how `DateTime` deserialization is supposed to work |
| 18 | + |
| 19 | +`LambdaEventSerializers.serializerFor()` registers a `DateTimeModule` (which extends `JodaModule`) on the mapper before returning the serializer: |
| 20 | + |
| 21 | +```java |
| 22 | +// LambdaEventSerializers.java line 262 |
| 23 | +factory.getMapper().registerModules(new DateModule(), new DateTimeModule(classLoader)); |
| 24 | +``` |
| 25 | + |
| 26 | +`DateTimeModule` registers a custom deserializer for `org.joda.time.DateTime` (the customer's unshaded class, via the pom reverse-transform workaround). This deserializer simply calls `DateTime.parse(jsonParser.getValueAsString())` and handles any String input correctly. |
| 27 | + |
| 28 | +### What broke in Jackson 2.18 |
| 29 | + |
| 30 | +`JacksonFactory` disables creator auto-detection: |
| 31 | + |
| 32 | +```java |
| 33 | +// JacksonFactory.java line 68 |
| 34 | +.disable(MapperFeature.AUTO_DETECT_CREATORS) |
| 35 | +``` |
| 36 | + |
| 37 | +Jackson 2.18 shipped a complete rewrite of `POJOPropertiesCollector` ([databind #4515](https://github.com/FasterXML/jackson-databind/issues/4515)), which moved creator detection logic from `BasicDeserializerFactory` into `POJOPropertiesCollector` and changed when it runs. |
| 38 | + |
| 39 | +With `AUTO_DETECT_CREATORS` disabled, no creators are found for `DateTime` during bean property collection. In Jackson 2.18's rewritten code path, when no creators are detected for a type, `_findCustomDeserializer()` — the lookup that would find `DateTimeModule`'s registered deserializer — is bypassed. Jackson falls straight through to building a `BeanDeserializer` for `DateTime`. |
| 40 | + |
| 41 | +The `BeanDeserializer` finds `DateTime()`'s no-arg constructor (which is not gated by `AUTO_DETECT_CREATORS`), so it reports "at least one Creator exists" — but that creator doesn't accept a String, hence the error. |
| 42 | + |
| 43 | +### Why it worked in 2.15.4 |
| 44 | + |
| 45 | +In Jackson 2.15.4, `_findCustomDeserializer()` was called **unconditionally**, regardless of whether creator detection found anything. So `DateTimeModule`'s registered deserializer was always found and used. That unconditional call was the fallback that 2.18 removed as part of the `#4515` rewrite. |
| 46 | + |
| 47 | +## Fix Options |
| 48 | + |
| 49 | +### Option 1 — Remove `.disable(MapperFeature.AUTO_DETECT_CREATORS)` from `JacksonFactory` |
| 50 | + |
| 51 | +Simplest fix. Jackson's default is enabled, so this aligns with standard behaviour. Risk: could enable constructor-based creator detection for customer POJOs, potentially changing deserialization semantics for handler inputs that have multi-arg constructors. The original intent behind disabling it is undocumented (present since the initial commit), so the blast radius is unknown. |
| 52 | + |
| 53 | +To confirm this is the cause: remove the line and run `testLoadCodeCommitEvent`. |
| 54 | + |
| 55 | +### Option 2 — Use `BeanDeserializerModifier` in `DateTimeModule` ✅ Recommended |
| 56 | + |
| 57 | +More targeted. Since Jackson 2.18 IS reaching `BeanDeserializer` for `DateTime` (confirmed by the error), `BeanDeserializerModifier.modifyDeserializer()` is called at that point. We can intercept it there and swap in the custom deserializer — without touching `AUTO_DETECT_CREATORS` at all. |
| 58 | + |
| 59 | +Add the following to the `DateTimeModule` constructor, after the existing `addDeserializer` call: |
| 60 | + |
| 61 | +```java |
| 62 | +this.setDeserializerModifier(new BeanDeserializerModifier() { |
| 63 | + @Override |
| 64 | + public JsonDeserializer<?> modifyDeserializer(DeserializationConfig config, |
| 65 | + BeanDescription beanDesc, JsonDeserializer<?> deserializer) { |
| 66 | + if (beanDesc.getBeanClass() == dateTimeClass) { |
| 67 | + return getDeserializer(dateTimeClass); |
| 68 | + } |
| 69 | + return deserializer; |
| 70 | + } |
| 71 | +}); |
| 72 | +``` |
| 73 | + |
| 74 | +This is scoped only to `DateTime`, leaves `AUTO_DETECT_CREATORS` untouched, and fixes exactly the broken code path without risk of side effects elsewhere. |
| 75 | + |
| 76 | +## Related Issues |
| 77 | + |
| 78 | +| Issue | Description | |
| 79 | +|-------|-------------| |
| 80 | +| [databind #4515](https://github.com/FasterXML/jackson-databind/issues/4515) | Rewrite of `POJOPropertiesCollector` — root cause of the behaviour change | |
| 81 | +| [databind #4920](https://github.com/FasterXML/jackson-databind/issues/4920) | Regression introduced by #4515: custom module deserializers bypassed when creator detection finds nothing | |
| 82 | +| [databind #4982](https://github.com/FasterXML/jackson-databind/pull/4982) | Partial fix in 2.18.3, does not cover the `AUTO_DETECT_CREATORS = false` case | |
0 commit comments