Serializable objects should be deserializable between minor versions #3737
Comments
|
This issue affects users when using spring session with java serialization (i.e. Spring Redis with Java serialization) i.e. when upgrading our application to a new version of Spring Security on a Spring Session powered app using redis, we had the following error: |
spring-projects-issues
added
the
status: waiting-for-triage
|
Have there been any thoughts/progress on this? Without consistent means to (de)serialize core Spring Security objects, upgrades become very difficult. As well as Session storage, the same applies to Cache (e.g. used by Spring Security ACL) and OAuth implementations. Not even a There's a big difference between "we have avoided attempting to maintain a serializability contract between versions" and the current "we actively break all compatibility every version". JDK serialisation need not be the solution (though many people are already stuck there). If e.g. Jackson were able to serialise most classes that would go a long way, but the majority are not designed as beans. |
eleftherias
added
in: core
|
In order to do something like this we would need tests that ensure the serialization stays the same between versions. For each class, we would need a file with the serialized output and a test that reads the file to produce the present-day deserialized object. We would also need tests to ensure the present-day object can be serialized and then deserialized. We are not actively working on this at the moment, however, pull requests are welcome. |
No you don't. Again, we're not asking that you ensure it's always compatible, only that you stop deliberately making every minor version incompatible. All you have to do is stop changing the |
|
@OrangeDog In order to only change the |
|
@eleftherias most people know when a class is changed to be incompatible because they changed it to be incompatible. You also have code review in case they forget, and even if it's missed the worst thing that happens is you get a slightly different exception. |
|
The same affects HA update for environments using Tomcat session clustering. |
|
So, I'm getting this error. I'm a beginner and I don't know what to do about it. I get that serialisation is the saving of the (state of the?) class somewhere and since upgrading I assume it is trying to read it back from somewhere and is failing because the numbers are different. Where is it trying to read it back from? Should I care what is saved wherever it is saved? What can I do about this please? |
|
As SecurityContextImpl is saved into the session, upgrades of SpringSec possibly will always lead to SerializationException when running in clustered environments. For such classes, which are serialized into the Session (Hazelcast, Redis), I strongly recommend to implement own writeObject() / readObject() methods to safely serialize independent of the global serialVersionUid (e.g. Mixin and CoreJackson2Module or https://github.com/jdereg/json-io). |
marcusdacoregio
changed the title
We should test that serialized files from the current minor version can be deserialized. This ensures that serializations remain deserializable in patch releases. Issue gh-3737
Currently after #1945
serialVersionUidis set for whole project, which means even if particular class is not changed between releases it'll be impossible to deserialize it due toserialVersionUidupdate. That could be solved by keepingserialVersionUidseparate for each class and update it only after the class is changed. Also providing some tests to check compatibility.The text was updated successfully, but these errors were encountered: