On 7 Dec 2003, at 18:27, Reinhard Poetz wrote:
>
> From: Geoff Howard
>
>>>
>>> No they won't when those are created by sessions. The servlet
>>> Container
>>> will set a cookie for the "/cocoon/" path... Since the web
>> application
>>> is proxied to "/" instead of "/cocoon/" the browser WILL
>> NOT pass back
>>> the 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
|