А кто-нибудь огребал проблем с java-десериализацией объектов, сохранённых в переменные процесса, при изменении соответствующего класса данных в новой версии приложения? Например, сохранили объект в переменную процесса, потом добавили необязательное поле в этот класс (по идее, это изменение с обратной совместимостью), выкатили новую версию приложения, а оно не может десериализовать ранее сохранённый объект?

В камунде ещё не наступал на эти грабли, подобная проблема когда-то встречалась безотносительно камунды.

Есть ли смысл сконфигурировать, чтобы по умолчанию в камунде использовалась json-сериализация, а не java-сериализация?

умножаем одно на другое и получаем экспотенциальный рост нагрузки на базу при добавлении новых переменных в контекст

можно убрать историю

Несколько помню, пока нет, но тоже вариант

Несколько помню, пока нет, но тоже вариант

Если Вы имплиментились от Serializable , то IDE должна была сама Вам подсказать что надо бы serialVersionUID указать, в противном случаи java сама высчитает его динамически.
я бы рекомендовал сериализацию в json самостоятельно делать. По скорости иногда даже быстрее чем стандартная java сериализация, но в случаи если Вы заходите посмотреть этот объект, то читаемый вид более понятен для разбора проблем

А зачем "самостоятельно"? Камунда же умеет JSON-сериализацию

А зачем "самостоятельно"? Камунда же умеет JSON-сериализацию

добрый день, отключается это дело вот так ? history-level: none

Мы от сериализации java ушли сразу почти. Проблемы с версионированием большие, да. С Json куда проще. Создавать свой провайдер для сериализации/десериализации совсем необязательно - достаточно выставить параметр в камунде:
camunda.bpm.default-serialization-format: 'application/json' и она, всё что сможет, сама завернёт. Если нужно добавить обработку null'ов пустых листов и т.п., аннотации от Jackson вполне справляются с этим, как и с игнорированием полей.

Спасибо, именно то, что я хотел услышать ;)