-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Spring Session fails to deserialize scoped Beans #395
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
This was referenced Feb 26, 2016
Closed
Waiting for feedback from the linked issues since this is not actually a Spring Session issue |
Also related spring-attic/spring-security-oauth#705 |
Closing since spring-attic/spring-security-oauth#705 has been resolved |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
When using Spring Session with scoped Beans (i.e. request / session / etc), the following error can occur:
This means that using Spring Session and Spring Security OAuth (which uses session and request scoped beans) can fail. The failure happens when
DefaultListableBeanFactory.serializationId
has a different value from when the serialization takes place and when the deserialization takes place. There are a few places in which this is might happen.Boot Applications
NOTE This is tracked at spring-projects/spring-boot#5265
In a Spring Boot application the ContextIdApplicationContextInitializer sets AbstractApplicationContext.id. Then in GenericApplicationContext.refreshBeanFactory() the id is set as the
DefaultListableBeanFactory.serializationId
.Unfortunately Spring Boot's ContextIdApplicationContextInitializer.getApplicationId derives the name of the id from the name of the application and the port the application is running on. This means if you have the same Spring Boot application running on different ports, Session Scoped beans will not work across between the two instances of the application.
This can be worked around by setting the application name and application index using something like this:
Unfortunately, this impacts other places where the application name and index are used to determine which instance of Spring Boot is being used.
Spring Cloud
NOTE This is tracked at spring-cloud/spring-cloud-commons#93
In Spring Cloud, the GenericScope.setSerializationId sets the serialization id. This means both
RefreshScope
andThreadScope
(which inherit fromGenericScope
) are impacted by this.The default value is a UUID calculated from the bytes of the Spring Bean names. Unfortunately the calculation of the resulting id does not appear to be constant. When the same application is restarted, the UUID is still different than the previous id.
This can be worked around by creating a
RefreshScope
bean definition. For example:Examples
You can find an example for reproducing this in rwinch/tut-spring-security-and-angular-js. Use the following instructions:
Use the following branches
Full Stacktrace
A full stacktrace can be found below:
Related to:
The text was updated successfully, but these errors were encountered: