Session persistence error: SerializedLambda cannot be cast to class com.vaadin.flow.data.provider.DataGenerator

Flow
1

Hi,

my Vaadin 24.3.x application consists of views with and without Grids. If the last visited view doesn’t have a Grid, then the hot-restart and session deserialization during dev-time works properly so that I do not have to login again.
But, if the last visited view contains a Grid, then there is a session deserialization error after the spring boot dev-tools hot-restarts the application.

In order to investigate this error I
a) add -Dsun.io.serialization.extendedDebugInfo=true to the run config
b) increase the log level for java.io.serializationand org.apache.catalina.sessionto trace

During examination, I’ve added some implements Serializableand final transientto my own code but without any success regarding those Grid views…

The Tomcat loads the session…

14:14:16 DEBUG o.a.catalina.session.StandardManager     Start: Loading persisted sessions
14:14:16 DEBUG o.a.catalina.session.StandardManager     Loading persisted sessions from [/Users/Dominik/temp/sessions/SESSIONS.ser]
14:14:16 DEBUG o.a.catalina.session.StandardManager     Loading 2 persisted sessions
14:14:16  INFO c.v.f.s.frontend.TaskCopyFrontendFiles   Visited 24 resources. Took 16 ms.
14:14:19 ERROR o.a.catalina.session.StandardManager     Exception loading sessions from persistent storage

But afterwards this error occur:

java.io.InvalidObjectException: ReflectiveOperationException during deserialization
	at java.base/java.lang.invoke.SerializedLambda.readResolve(SerializedLambda.java:280)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base/java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1192)
	at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2293)
	at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1762)

...

Caused by: java.lang.reflect.InvocationTargetException: null
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:109)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base/java.lang.invoke.SerializedLambda.readResolve(SerializedLambda.java:278)
	... 249 common frames omitted
Caused by: java.lang.ClassCastException: class java.lang.invoke.SerializedLambda cannot be cast to class com.vaadin.flow.data.provider.DataGenerator (java.lang.invoke.SerializedLambda is in module java.base of loader 'bootstrap'; com.vaadin.flow.data.provider.DataGenerator is in unnamed module of loader 'app')
	at com.vaadin.flow.data.provider.CompositeDataGenerator.$deserializeLambda$(CompositeDataGenerator.java:39)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	... 251 common frames omitted

What to do to fix that session deserialization error ?

2

Are you using LitRenderer in those grids? I’m wondering if this recently merged fix would apply to your issue as well fix: prevent potential deserialization issue in LitRenderer (#6257) (CP: 24.3) by vaadin-bot · Pull Request #6261 · vaadin/flow-components · GitHub
It hasn’t been released yet but you can to try it by overriding the version of vaadin-renderer-flow to 24.3-SNAPSHOT, you will also need to vaadin-prereleases maven repository with snapshots enabled (https://maven.vaadin.com/vaadin-prereleases)
Othewrise the next 24.3 release should happen next week.

1 Like
3

Hi Guillermo,

thank you for your fast response.
The workaround you mentioned seems to work :slight_smile:
But now I get the frquently seen

java.lang.ClassCastException: class java.io.ObjectStreamClass cannot be cast to class java.lang.String (java.io.ObjectStreamClass and java.lang.String are in module java.base of loader 'bootstrap')

but without any details regarding which class can’t be de/serialized. Or is this error something different and adding some missing implements Serializableor transient didn’t help, apart from the fact that i don’t even know which classes would be affected.

kind reagrds
Dominik

4

That doesn’t ring a bell unfortunately. I wonder if the suggestion from this stackoverflow answer to check the content of SESSIONS.ser can be of help.