However, my Vaadin application refuse to work as soon as Spring sessions are involved and the following message appears in the debug console:
“Response didn’t contain a server id. Please verify that the server is up-to-date and that the response data has not been modified in transmission.”
Am I missing something here? I’m not sure if I need to make additionnal changes in order for this to work.
I’ve been playing a bit with Spring Session and Vaadin and run into the same issue. It seems that data in the session is sent to the Redis server before the
VaadinSession instance has been fully configured which causes an old version of the instance to be persisted in Redis. Unfortunatelly, the fix would be easier to implement if the
RedisOperationsSessionRepository class had some extension mechanisim regarding “deltas” and “caches”. The only workaround I have found so far is to use a
modified version of that class .
I’ve tried your proposed solution with my project. Using the modified
RedisOperationsSessionRepository class seems the problem described above, however I now get an NullPointerException on the server side.
java.lang.NullPointerException: null
at org.springframework.session.data.redis.RedisOperationsSessionRepository$RedisSession.saveDelta(RedisOperationsSessionRepository.java:788)
at org.springframework.session.data.redis.RedisOperationsSessionRepository$RedisSession.access$0(RedisOperationsSessionRepository.java:781)
at org.springframework.session.data.redis.RedisOperationsSessionRepository.save(RedisOperationsSessionRepository.java:401)
at org.springframework.session.data.redis.RedisOperationsSessionRepository.save(RedisOperationsSessionRepository.java:1)
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.commitSession(SessionRepositoryFilter.java:244)
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.access$100(SessionRepositoryFilter.java:214)
at org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:167)
at org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:80)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
The call to
VaadinService.getCurrent() returns null the third time it gets called somehow. Maybe the Vaadin context is not present somehow on that third call. Any hints?
Hi,
Serializing each and every component used in UI or VIEW is insane! I have few questions, please help me to get through, I’m stuck!
Do I really need to serialize every component injected into UI or View ? is there any workaround ?
Even when I serialize each piece, it’s complaining VaadinManagedSecurity not serialized!! What should I do ?
Lastly, we know serialization should be used judiciously, wrapping every component (including spring services) doesn’t introduce performance issue as tradeoff doing session externalization ?
Yes, when the UI contains too many UI components, serializing the session might become a problem, mostly in distributed systems where replication occurs.
You can use the
transient keyword to avoid serializing fields you don’t need to serialize. Alternatively, you can get instances from an external helper class/service instead of letting a framework (Spring?) inject them in the class scope.
I guess
VaadinManagedSecurity comes from a third-party library. You should check with the author about it.
The more fields you need to serialize, the more computation time is required. This is important mostly when you want to replicate the session in a cluster.
Use sticky sessions disable session replication. All advices make things transient will cause that the client serialized session will be invalid after deserialization. you will got a plenty NPE.