BlazeDS, whether used in combination with spring blazeDS integration or not, creates a session attribute with key __flexSession and of type HttpFlexSession. This object maintains a circular link back to the HttpSession. When the old session is invalidated on login, the default behaviour is to copy all attributes across. The __flexSession attribute is copied, but the reference to the original HttpSession within it is left intact. In fact, it is a private member that is only set via private constructor, so it is impossible to update.
It is possible that the flex session can be cloned in much the same way as the HttpSession, but in order to do so, one would have to override SessionUtils, butt that class is both static and final, so it isn't possible to simply inject our own subclass of SessionUtils which knows how to take care of the __flexSession attribute. Instead, we were forced to create a class of the same name and package and place it earlier in the classpath, which is a pretty ugly kludge which will cause our codebase to persist any errors that might be fixed in subsequent releases.
I think the correct fix for this is to create a bean out of SessionUtils, inject it where appropriate, and then allow the blazeds integration team to provide an alternate SessionUtils class which knows how to handle the HttpFlexSession. AT the very least, the flex session can be dropped and not copied across, but ideally, the correct mechanism for cloning it can be called and the flex session attributes can be retained. The blazeDS documentation isn't terribly enlightening when it comes to documenting the side effects of attempting to clone the various properties and attributes of the HttpFlexSession, so a bit of research is required before anything other than dropping that attribute is adopted as a solution.
A link to the bug I created over on the blaze ds jira is: http://bugs.adobe.com/jira/browse/BLZ-350
Incidentally, if the __flexSession attribute is copied over to the new session with the reference to the old HttpSession intact, it results in invalid session exceptions being thrown on every blaze ds call.