Session persistence broken from 9.4.13+

[stephenc]

Background

#2964 introduced switchable classloaders for session data.

I understand the intent of such switchable classloaders, but the simple switching mechanism is flawed and potentially breaks lots of web applications (and certainly breaks a lot of frameworks when running jetty in embedded mode or when installing the framework as a module)

Bug

The basic flaw in the current implementation is in https://github.com/eclipse/jetty.project/blob/29b960551f59d3c455fabdd657b207fc5898fb4c/jetty-server/src/main/java/org/eclipse/jetty/server/session/SessionData.java#L74-L95

Basically, the switch of the classloader happens based on the classloader of the session value.

Where this can break web applications is for example, if I store an ArrayList<MyClass> in the session. Because only the top reference's classloader is checked, this will be serialized with isServerLoader == true because java.util.ArrayList always comes from the server classloader. Then when deserializing, the server classloader will be used, and as that doesn't have the MyClass definition (it's only in the webapp classloader) the session will fail to deserialize and be marked as invalid... or worse, in embedded mode the MyClass definition will be loaded from the server classloader and then the web application will get a ClassCastException when they try to access the session state.

Workaround

Use Jetty 9.4.12.v20180830

Impact

This would seem to be a rather severe regression as it has the capacity to break user's web application session serialization.

[joakime]

PR #3598 opened

[joakime]

Do you have a demo webapp that produces this issue?

[stephenc]

I have some unit tests in Apache OpenWebBeans!

If you change the jetty.version property at https://github.com/apache/openwebbeans/pull/14/files#diff-600376dffeb79835ede4a0b285078036R74 to anything newer than 9.4.12 then this unit test https://github.com/apache/openwebbeans/pull/14/files#diff-ffb9e65df6fd13bd90699a9a596fe45aR50 will start to fail.

It took @struberg and I a while to diagnose but the root cause is this:

• When running Jetty in embedded mode (or with OWB deployed as a jetty module rather than bundled in the .WAR) then OWB's classes will come from the server classloader.
• OWB stores its SessionContext class in the Session so that it can maintain the @SessionScoped beans
• When the session is persisted, Jetty's SessionData sees the value as having a classloader that is not the webapp classloader, but either the system or parent classloader (depending on embedded or module deployment and the direction of the wind) so it records the class as being isServerLoader
• When deserializing in embedded mode (like in a test) - because the classes are also available from the embedded classloader the Bean Manager is able to bootstrap but we get a class cast exception because it bootstrapped the wrong context
• When deserializing in Jetty module mode (or in embedded mode where you provide a WAR) the Bean Manager bootstraps an empty context or fails to deserialize the classes because they cannot be found.

[janbartel]

Fixed in 9.4.18 and beyond.