Again and again I find myself in searching for classes that do not implement Serializable interface but are set into session. When you have such a class you just see in the log at tomcat start that there was a problem while deserializing the session object. I would be very helpful if the log would say which attribute have caused the problem. Sample implementation StandardSession.java in doReadObject(ObjectInputStream stream): Instead of: for (int i = 0; i < n; i++) { String name = (String) stream.readObject(); Object value = stream.readObject(); if ((value instanceof String) && (value.equals(NOT_SERIALIZED))) continue; if (manager.getContext().getLogger().isDebugEnabled()) manager.getContext().getLogger().debug(" loading attribute '" + name + "' with value '" + value + "'"); attributes.put(name, value); } do: for (int i = 0; i < n; i++) { String name = (String) stream.readObject(); Object value = null; try { value = stream.readObject(); } catch (Exception e) { manager.getContext().getLogger().error(String.format("Attribute %s could not be deserialized due to %s", name, e.getMessage())); } if ((value instanceof String) && (value.equals(NOT_SERIALIZED))) continue; if (manager.getContext().getLogger().isDebugEnabled()) manager.getContext().getLogger().debug(" loading attribute '" + name + "' with value '" + value + "'"); attributes.put(name, value); }
Care to prepare a formal patch?
Created attachment 34324 [details] Proposed a patch for 8.0.x Added a patch
I'm not completely against this but... The error is logged, with the attribute name when writing the session to disk. Why do you need another error message when reading it?
I never saw such a warning on the tomcat shutdown. And I just tested it, and I don't any warning still. But I see the line you meant in the code of StandardSession.doWriteObject: manager.getContext().getLogger().warn( sm.getString("standardSession.notSerializable", saveNames.get(i), id), e); In the debugger I see the line executed not I don't see any output in my logs. Really strange. (This is a Spring Boot project with devtools) Still I think telling the name of the attribute which caused the problem on the tomcat start would be helpful, because one would know right away what the problem is, and he does not need to know that there was a message in the shutdown log which nobody every reads.
With the proposed patch the error is logged higher up the stack. I suspect a logging configuration issue. The users list is the place to seek help with that. The proposed patch also causes deserialization to stop on the first error. That is not the desired behaviour. I have an alternative patch that I'll apply shortly that logs a warn message with the attribute name or a debug message that includes the stack trace.
Mark, great! Thank you.
This has been fixed in the following branches: - 9.0.x for 9.0.0.M11 onwards - 8.5.x for 8.5.6 onwards - 8.0.x for 8.0.38 onwards - 7.0.x for 7.0.73 onwards