cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] improving the session concept
Date Tue, 08 Apr 2003 08:53:04 GMT
on 4/8/03 3:52 AM Tony Collen wrote:

> On Tue, 8 Apr 2003, Stefano Mazzocchi wrote:
> <snip/>
>>>>The really kick-ass thing would be to have a way to push an event
>>>>listener into the session, that it gets called when the session expires.
>>>>The problem is that the servlet API doesn't include this and there is no
>>>>(portable) way to hook cocoon into the *real* session.
>>>I don't understand what you're saying... Why can't we build the abstract
>>>cocoon session code around javax.servlet.http.HttpSessionListener ?
>>Ah, you're right. I overlooked that. Thanks for catching.
> In my eyes, the flow continuations seemed sort of like sessions, they
> appear to act like super-sessions in a way.  Have you given any thought
> into combining the concepts of flow and sessions together?

they are already working together rather smoothly. when you do something
like this:

 var state = "";

 function foo() {
    sendPage('foo', { state : state });
    state = 'foo';

 function bar() {
    sendPage('bar', { state : state });
    state = 'bar'

there is no continuation going on, still the global variable is kept as
a state between different calls. This is done transparently by the flow
manager if the session is available.

> On a parallel, the flow continuations expire, how about using the
> cornerstone components to create a mechanism for expiring sessions?

Sessions are fully controlled by the underlying servlet container, the
servlet API uses IoC so doesn't give you hooks to dispose them.

Anyway, Pier is right, we can use the unboundle events as a
signification that the session has been expired and its values unboundled.


View raw message