The method iterates throw available tomcatSessionCoverters and if none is able to deserialize dynamodb it throws SessionConversionException supression the real cause. Now imaging this happens in production and there is no way to tell what is the reason.

Method must NOT consume original SessionConversionException.

A quick possible solution is if we reach that point where
"throw new SessionConversionException("Unable to convert Dynamo storage representation to a Tomcat Session with any converter provided");" then:

1. option: we add a collection of previous exceptions generated by converter.toSession(sessionItem) so administrator/dev can analyze what the issue is.

2. Not re throw, but add a logger into TomcatSessionConverterChain

3. Throw Catch clause should NOT be used for expected normal flow control. if-else for, while etc should. This is a small design flaw to me. converter.toSession() should understand know if it can handle object of this type. Usually similar ideas are implemented by isSupported method. This may be more labor intensive to do as it will require some kind of marker how DynamoDBSession was created and what it's type. SessionConversionException should be thrown ONLY IF: a) supported converter has failed. b) no supported converter was found.

4. I think it is very important for some cases: add a configuration option to enforce recreation of new session object if the old one can not be deserialized. It's quite common case that someone can forget to add serialVersionUID and object can not be restored after recompilation. This flag would at least allow to tolerate this until next tomcat restart.

Thank you.

DynamoSessionItemConverter