From: Geoff Howard
application
No they won't when those are created by sessions. The servlet Container will set a cookie for the "/cocoon/" path... Since the webis proxied to "/" instead of "/cocoon/" the browser WILLNOT pass backthe session ID to the server...
Pardon my ignorance, but doesn't that mean you can't use flow with such a system?
Why do you think so? The only difference is the continuation-id which can be part of the URL or a request parameter ... so I don't think a load balancing approach prevents flow from working. The only issue open is the continuations tree which is stored in a global component and not in the session. IIUC this is a problem in clustered environments, isn't it? (IIRC there was a discussion some weeks ago, Thorsten what do you think?)
as I said before, simply mount your webapp on where you want to have it deployed on the proxying front end and you'll be safe (no tricky rewrite rules UNLESS you don't know what you're doing)...
Regarding contination IDs it depends on where that is stored. If it's stored in the HttpSession and you are using cookies, then you have troubles, otherwise no troubles at all...
Of course if you're deploying on clustered environments, then you have to redirect the continuation to the JVM that holds it, so you either need to look (on the proxy) at the continuation ID, or if that is stored in the session to the Session ID and redirect accordingly...
Regarding continuation IDs, it might be great to have a config parameter in the Flow (in cocoon.xml) where you can specify something like an unique-id which can be used to uniquely identify the JVM that created that ID and holds the continuation itself...
Pier
