Во-первых, версии GemFire, на которые вы ссылаетесь, - это Spring Session для версий Pivotal GemFire (например, Spring Session Data GemFire (SSDG) 2.1.2.RELEASE; см. здесь).
К вашему сведению, чтобы определить фактическую версию Pivotal GemFire, вы должны следовать транзитивным зависимостям. Например, SSDG 2.1.2.RELEASE зависит от Spring Data для Pivotal GemFire (SDG) Lovelace / 2.1.3.RELEASE. SDG 2.1.x, в свою очередь, зависит от Pivotal GemFire 9.5.2. 9.5.2 - это используемая здесь версия Pivotal GemFire.
Касательно...
Могу ли я использовать сериализацию Java для объекта внутри сеанса в версии 2.1.2?
Да!
В общем, если объекты домена вашего приложения (например, Customer), хранящиеся в (HTTP) Session как Session значение атрибута 1) равны java.io.Serializable, 2) НЕ существует "зарегистрированный" PdxSerializer или DataSerializer способный де / сериализовать ваше приложение объекты домена 3) и ни один из объектов домена вашего приложения (например, Customer) не реализует _ 15_ или PdxSerializable, то ваши объекты должны быть сериализованы с использованием сериализации Java и, следовательно, будут сериализованы с использованием сериализации Java или сериализации. ion Возникнет исключение. Это особенно верно в любое время, когда GemFire отправляет данные между клиентом и сервером, между одноранговыми участниками в кластере (т. Е. Распределенной системе), по топологии WAN или в любое время, когда GemFire переполняет / сохраняет данные на диске. Если собственные структуры сериализации и механизмы GemFire не используются , то в качестве стратегии резервной сериализации применяется сериализация Java (если разрешена).
SSDG осторожен при де / сериализации объекта Session и его содержимого для передачи обратно в GemFire для применения логики сериализации к содержимому (объекты домена приложения, хранящиеся в) Session, особенно когда GemFire Платформа сериализации данных используется для де / сериализации объекта Session сам, что в вашем случае, так как вы настроили ...
sessionSerializerBeanName =
GemFireHttpSessionConfiguration.SESSION_DATA_SERIALIZER_BEAN_NAME
Технически вы можете увидеть это делегирование, начиная с объекта Session (здесь), который пишет атрибуты Session (ключи / значения), которые будут делегированы "зарегистрированным" и предоставленные SSDG, класс DataSerializationSessionAttributesSerializer, который сериализует значения атрибутов Session делегатом обратно в GemFire, здесь.
Вспомогательный метод SSDG serializeObject(:Object), в свою очередь, просто делегирует GemFire _ 26_ метод, здесь . allowJavaSerialization по умолчанию истинно, см. здесь, затем здесь).
На данный момент все в руках Pivotal GemFire (после делегирования SSDG). Как правило, Pivotal GemFire использует следующий алгоритм для применения де / сериализации к любому объекту:
1) Сериализация PDX 2) Сериализация данных 3) Сериализация Java
Следуя правилам, изложенным выше. Вы можете увидеть эту логику, реализованную в классе InternalDataSerializer, используемом GemFire, здесь. В конечном итоге сериализация Java происходит здесь, если это разрешено.
Касательно...
Какую аннотацию или атрибут нужно использовать для сериализации объектов внутри объекта сеанса с помощью сериализации Java?
Нет аннотаций и / или атрибутов для применения сериализации Java; это стратегия сериализации по умолчанию / откат, используемая, когда никакие другие параметры не были явно настроены.
Это означает, что вы определенно не хотите использовать SDG _ 29_, поскольку SDG позволяет очень легко 1) определить типы, подходящие для де / сериализации с помощью PDX и 2) де / сериализовать те объекты в потоке байтов PDX. Более подробную информацию можно найти в справочной документации о PDX здесь вместе с подробностями о SDG MappingPdxSerializer (который @EnablePdx применяется внутри, как настроенный / зарегистрированный PdxSerializer, используемый GemFire), здесь.
Также не забудьте ознакомиться с документацией по данным Pivotal GemFire. Сериализация и как это работает.
Надеюсь это поможет!
person
John Blum
schedule
12.02.2019
