Skip to content

Reserializing a lenient fallback DefaultListableBeanFactory causes an error [SPR-17508] #22040

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Nov 16, 2018 · 1 comment
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 16, 2018

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 a DefaultListableBeanFactory.

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:

Referenced from: commits f5aeb81, 37a50d7, 22f4b1c

Backported to: 5.0.11, 4.3.21

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Using a dummy factory with dummyFactory.serializationId = this.id seems to do the trick, just storing the serialization id but not actually exposing the factory in the static map. Thanks for raising this; I'll commit and backport it ASAP!

@spring-projects-issues spring-projects-issues added type: bug A general bug status: backported An issue that has been backported to maintenance branches in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.1.3 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants