Description
hwanders opened SPR-17508 and commented
In #20321 the deserialization of DefaultListableBeanFactory.SerializedBeanFactoryReference
was changed:
- Instead of resolving a not-found ID to a
StaticListableBeanFactory
, it is now resolved to aDefaultListableBeanFactory
.
The old StaticListableBeanFactory
does not implement Serializable
while DefaultListableBeanFactory
indeed does.
When obaining such a lenient fallback DefaultListableBeanFactory
from SerializedBeanFactoryReference#readResolve
, it does not get a serializationId
assigned.
This causes later reserializations [and they may appear, since the class implements Serializable
] to fail with a NotSerializableException("DefaultListableBeanFactory has no serialization id")
.
Maybe the desired ID (which could not be looked up in the static map serializableFactories
) should be used:
// Lenient fallback: dummy factory in case of original factory not found...
DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
// make the factory effectively serializable
factory.setSerializationId(this.id);
return factory;
But perhaps this causes undesired side-effects because other dead references to the same factory will become alive when they are deserialized in later calls (they will find the registered dummy factory).
This is actually happening in our software when opening our web application, using an old session containing an OAuth2ClientContext
after changing the application's bean definitions.
We are using the spring-boot-starter-parent
1.5.7 but some tests on 1.5.17 (which uses 4.3.20) indicate that this is still an issue.
Affects: 4.3.20
Issue Links:
- ClassCastException during deserialization of ScopedObject [SPR-15766] #20321 ClassCastException during deserialization of ScopedObject