Aggregate Snapshotting: Choosing the correct Serializer (or Aggregate [,pair]))

Hi there,

in the docs on Snapshotting (Event Snapshots - Axon Reference Guide) under the segment Serializing a Snapshot Event (Event Snapshots - Axon Reference Guide)
the docs say:

Do make sure the Serializer instance you use (which defaults to the XStreamSerializer ) is capable of serializing your aggregate. The XStreamSerializer requires you to use either a Hotspot JVM, or your aggregate must either have an accessible default constructor or implement the Serializable interface.

What Serializer is apt here or what type of Aggregate and how would I configure an apt type of Aggregate?

Considering the Serializer, would the Jackson Serializer do?


Probably, typically in an aggregate you have some private fields, without a public getter. Adding a public getter is a way to make sure those fields are serialized with Jackson.

Hello @gklijs

Ok, but apart from a non-private constructor

  1. Is Jackson a compossible Serializer for Snapshots?
  2. Are there special Aggregate Types say if I use certain Command-, Event- or Query Processors that implement the interface while other Axon Aggregate Types do decidedly not do this?

Thanks !

To be clear, it’s not just about the constructor. The aggregate state needs to be publicly available, which is easy to forget. But Jackson is a lot easier in my experience, especially when using java collections in the aggregate, than XTream, especially when easier newer Java/JDK versions.

I’m not sure what you mean by the second question. An aggregate is a class annotated with the @Aggregate annotation. How it’s used doesn’t matter much for how it needs to be snapshotted.

1 Like

I recommend to write unit tests for serializability.

Serialize and Deserialize your aggregate with e.g. all fields set and with only the mandatory fields set with the serializer and its configuration. Assert that the aggregate fields are correctly reconstructed. Do this for every aggregate.

This reduces surprises at runtime. If you make a change that breaks serializability, you will see it right away and spot on. You don’t have to wait for integration tests to fail or worse, test or production system issues.