-
Notifications
You must be signed in to change notification settings - Fork 38.5k
ClassCastException during deserialization of ScopedObject [SPR-15766] #20321
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
Comments
Dave Syer commented Stack trace:
|
Dave Syer commented Test case here: spring-attic/spring-framework-issues#163. I have more long-winded versions of the test that use Spring Session and Redis for force the serialization to happen, rather than doing it manually in the controller (more like the original issue in Spring Session). If that is useful I can patch the sample. |
Juergen Hoeller commented OK, so I guess falling back to an empty |
Dave Syer opened SPR-15766 and commented
A
ScopedObject
(as is created by a@Bean
in@SessionScope
for example) has a reference to theBeanFactory
that created it, and when it is serialized and deserialized theBeanFactory
is re-hydrated by looking it up in a global map.The fix for #18689 made this process more robust, but it has now exposed another corner case because the
StaticListableBeanFactory
that it creates as a fallback is not aConfigurableBeanFactory
, and aDefaultScopedObject
has a field of that type, so when it is deserialized there is a class cast exception.Affects: 4.3.9
Reference URL: spring-projects/spring-session#799
Issue Links:
Referenced from: commits c9ffa64, fd2b4f2
The text was updated successfully, but these errors were encountered: