First, the versions of GemFire to which you refer are Spring Session for Pivotal GemFire versions (e.g. Spring Session Data GemFire (SSDG) 2.1.2.RELEASE; see here).
FYI, to determine the actual version of Pivotal GemFire, you must follow the transitive dependencies. For instance, SSDG 2.1.2.RELEASE depends on Spring Data for Pivotal GemFire (SDG) Lovelace / 2.1.3.RELEASE. SDG 2.1.x in turn depends on Pivotal GemFire 9.5.2. 9.5.2 is the Pivotal GemFire version in use here.
Regarding...
Can I use Java Serialization for object inside the Session in 2.1.2 version?
Yes!
In general, if your application domain objects (e.g. Customer), stored in the (HTTP) Session as a Session attribute value 1) is java.io.Serializable, 2) there does NOT exist a "registered" PdxSerializer or DataSerializer capable of de/serializing your application domain objects 3) nor does any of your application domain objects (e.g. Customer) implement DataSerializble or PdxSerializable, then your objects must be serializable using Java Serialization and therefore, will be serialized using Java Serialization, or a Serialization Exception will occur. This is particularly true anytime GemFire sends data between client and server, between peer members in a cluster (i.e. distributed system), over a WAN topology, or anytime GemFire overflows/persists data to disk. If GemFire's own Serialization frameworks and mechanics are not used, then Java Serialization (if allowed) is the fallback serialization strategy applied.
SSDG is careful when de/serializing the Session object and it contents to delegate back to GemFire to apply serialization logic to the contents of (application domain objects stored in) the Session as well, especially when GemFire's Data Serialization framework is used to de/serialize the Session object itself, which in your case, it is since you have configured...
sessionSerializerBeanName =
GemFireHttpSessionConfiguration.SESSION_DATA_SERIALIZER_BEAN_NAME
Technically, you can see this delegation, starting with the Session object (here), which is writing the Session attributes (key/values), which will delegate to the "registered", and provided by SSDG, DataSerializationSessionAttributesSerializer class, which will serialize the Session attribute values by delegate back to GemFire, here.
The SSDG serializeObject(:Object) helper method in turn just delegates to GemFire's DataSerializable.writeObject(:Object, :DataOutput, allowJavaSerialization:boolean) method, here. allowJavaSerialization is true by default, see here, then here).
At this point, it is all in Pivotal GemFire's hands (after the delegation by SSDG). In general, Pivotal GemFire uses the following algorithm to apply de/serialization to any object:
1) PDX Serialization
2) Data Serialization
3) Java Serialization
Following the rules I outlined above. You can see this logic carried out in the InternalDataSerializer class used by GemFire, here. Ultimately, Java Serialization happens here, iff allowed.
Regarding...
Which annotation or attribute needs to be used for serializing objects inside the Session object using Java Serialization?
There are no Annotations and/or attributes to apply Java Serialization; it is the default/fallback serialization strategy used when no other option has been explicitly configured.
This mean you definitely do not want to use SDG's @EnablePdx annotation since SDG makes it very easy to 1) identify the types eligible for de/serialization with PDX and 2) to de/serialize those objects in a stream of PDX bytes. More details can be found in the ref docs about PDX here along with details about SDG's MappingPdxSerializer (which @EnablePdx applies under-the-hood, as the configured/registered PdxSerializer used by GemFire), here.
Also, remember to review Pivotal GemFire documentation on Data Serialization, and how it works.
Hope this helps!
