https://bz.apache.org/bugzilla/show_bug.cgi?id=58284
Bug ID: 58284
Summary: StandardSession attempts to silently write
NonSerializable objects
Product: Tomcat 8
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: sho...@amazon.com
Customer reported an issue with non-serializable objects when using our
DynamoDB Session manager
(https://github.com/aws/aws-dynamodb-session-tomcat/issues/30). After digging
into the code it looks like StandardSession is attempting to do several things
when giving non-serializable attributes. For top level objects that don't
implement serializable it silently removes it. That code is working fine
although I am a little wary that it doesn't fail as this could hide bugs in the
users code and make it difficult for them to determine why a certain attribute
isn't being persisted to the backing store. After that StandardSession attempts
to write the remaining attributes to the ObjectOutputStream. If a serialization
exception is encountered here (i.e. some object in the object graph does not
implement Serializable) then the exception is caught and a special indicator
NOT_SERIALIZED is written to the object stream and a warning is logged. Now
internally ObjectOutputStream is handling the same exception and writing it's
own special marker, TC_EXCEPTION, and the serialized exception object to the
stream. This is written before StandardSession has a chance to write
NOT_SERIALIZED. In StandardSession.readObject there is logic to skip
deserializing any objects that have been written to the stream as
NOT_SERIALIZED. This code can never actually be executed though as
ObjectInputStream is checking if there are any occurences of TC_EXCEPTION and
will deserialize the exception object, wrap it in a WriteAbortedException and
throw it out. This causes a session with non-serializable objects in the
attributes to be written "successfully" but causes an exception to be thrown
when attempting to read that same session.
I understand modifying StandardSession to now throw exceptions when
non-serializable objects are encountered could be considered a breaking change
so I propose adding some kind of overload or configuration to enable this
behavior for users that want to opt in. Failing fast when non-serializable
attributes are detected seems like the right way to go as this should be fixed
in the customers code. I'm willing to submit a patch for this although I wanted
to open the issue first to make sure you concur with my assessment and coding
up a patch is worth my time.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
