I have the impression you fixed the jvmRoute in the new Session(-Id) in ManagerBase, but not in DeltaManager? Even when the context is distributable one might prefer to stick the session to the node where it now originates.
Furthermore: I did not really understand the use case of emptySessionPath, but want to indicate 2 problematic areas: 1) If the cookie contains an expired session(-id) then you would allow a new session to be started with the old id. That is not a naive security problem, because the session is empty, so authentication has to be done again etc. But there is a more complex threat: Security of webapps relies on the fact, that session ids are not easily guessable. Once you move into a situation where a user might use the same session id for a very long time (in fact different sessions) the id will loose it's security. Normally it's hard to find out the id of a user session while the session is still active. And the user can at every time end his session. If he is going to use the same Id for many sessions you have a much better chance to get knowledge about the id between sessions and then to just wait for a new session to begin. 2) There might be problems by putting an arbitrary string coming from an uncontrolled Cookie and using it as a session id inside tomcat. I don't know, if there is a way related to cross site scrpting or injection of malicious code for cookies (of course I know, that there is no scripting inside Cookies, but atackers are very ingenious nowadays). At least one should check the string for formal correctness (e.g. containing only letters and numbers or something similar). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]