pjfanning opened a new issue, #3671: URL: https://github.com/apache/pekko/issues/3671
`pekko-serialization-jackson` (Jackson 2) and `pekko-serialization-jackson3` can't currently be used in the same runtime. Both modules' `reference.conf` files register serializers under the same names and identifiers: | | `serialization-jackson` | `serialization-jackson3` | |---|---|---| | `pekko.actor.serializers.jackson-json` | `...jackson.JacksonJsonSerializer` | `...jackson3.JacksonJsonSerializer` | | `pekko.actor.serializers.jackson-cbor` | `...jackson.JacksonCborSerializer` | `...jackson3.JacksonCborSerializer` | | `pekko.actor.serializers.jackson-cbor-264` | `...jackson.JacksonJsonSerializer` | `...jackson3.JacksonJsonSerializer` | | identifiers | 31 / 33 / 32 | 31 / 33 / 32 | If both jars are on the classpath, whichever `reference.conf` is merged last wins. All bindings, including both modules' predefined `JsonSerializable` / `CborSerializable` markers (#3649), then route to that one serializer. This also affects the manifest-less (`type-in-manifest = off`) type inference fixed in #3666: each module excludes only its own marker classes, so the other module's markers still count as bindings. Being able to load both modules would allow a gradual Jackson 2 → 3 migration, and lets libraries that depend on different modules be combined. ### Suggested changes (in `serialization-jackson3`) - Give the Jackson 3 serializers their own names (e.g. `jackson3-json`, `jackson3-cbor`, `jackson3-cbor-264`). The per-binding config under `pekko.serialization.jackson3.<binding-name>` would follow the new names. - Give them new identifiers from the reserved 0–40 range. 37, 38 and 40 appear to be unused (27 and 29 too, unless they are being held back). - Consider renaming the Jackson 3 marker traits (e.g. `Jackson3JsonSerializable` / `Jackson3CborSerializable`). Their FQCNs already differ by package, but distinct simple names avoid import confusion when both modules are present. ### Things to decide - **Wire/persistence compatibility.** Today, swapping the Jackson 2 module for the Jackson 3 one keeps identifier 31/33 data readable. With new identifiers, Jackson 3 users migrating from Jackson 2 need a way to read the old identifiers. Two options: keep the Jackson 2 module loaded for reading, or add an opt-in setting so the Jackson 3 serializers also claim 31/32/33 when the Jackson 2 module is absent. - Data written by the 2.0.0 milestone releases with `serialization-jackson3` uses identifiers 31/33. Milestones carry no compatibility promise, but this should be noted in the migration guide. This should land before 2.0.0 final, since `serialization-jackson3` has only shipped in milestones so far. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
