Menu
▾
▴
springframework-developer
|
From: Erwin V. <erw...@er...> - 2005-03-31 19:34:33
|
The Spring Web Flow (SWF) FlowController forces the "requireSession" property it inherits from AbstractController to "true". This is logical since the webflow system needs to store flow execution state in the HTTP session. So far so good. However, since the controller now requires an existing session, the user/developer is responsible for creating that session before a flow is started. This is typically not a problem in real-life applications since those carefully manage session creation and invalidation. Still, we are wondering whether it is a good idea to implicitly create sessions (usually using request.getSession()) in a controller, or should this be left as a responsability of the application developer? Note that AbstractWizardFormController and AbstractFormController implicitly create sessions. Erwin Vervaet erw...@er... |
|
From: Rob H. <ro...@ca...> - 2005-03-31 20:17:03
|
I see no problem in implictly creating a session - although I am concerned about the impact of this on clustered applications. Can the session implementation be factored out so that users can implement their own session storage? Rob Erwin Vervaet wrote: > The Spring Web Flow (SWF) FlowController forces the "requireSession" > property it inherits from AbstractController to "true". This is > logical since the webflow system needs to store flow execution state > in the HTTP session. > > So far so good. However, since the controller now requires an existing > session, the user/developer is responsible for creating that session > before a flow is started. This is typically not a problem in real-life > applications since those carefully manage session creation and > invalidation. > > Still, we are wondering whether it is a good idea to implicitly create > sessions (usually using request.getSession()) in a controller, or > should this be left as a responsability of the application developer? > Note that AbstractWizardFormController and AbstractFormController > implicitly create sessions. > > Erwin Vervaet > erw...@er... > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/info/Sentarus/hamr30 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Seth L. <set...@gm...> - 2005-03-31 23:17:43
|
On Thu, 31 Mar 2005 21:17:02 +0100, Rob Harrop <ro...@ca...> wrote: > I see no problem in implictly creating a session - although I am > concerned about the impact of this on clustered applications. Can the > session implementation be factored out so that users can implement their > own session storage? Hi Rob, One possible way here is to write your own impl of HttpSession and replace the builtin impl using a Filter. You can then perform whatever custom session storage you need. Seth |
|
From: James E. <jam...@gm...> - 2005-03-31 20:19:21
|
I was actually digging through the code earlier and debating the same thing. My first instinct was that it should create one for me if it is required anyway. I was thinking it would make sense to add a boolean 'createSessionIfNecessary' field on the org.springframework.web.servlet.support.WebContentGenerator. If true, the session will be created, otherwise an exception will be thrown as it is now. The only downside I could think of was when the session times-out while mid-flow (user waits too long) and data from the previous steps in the flow are not present (and the next steps are assuming the data is present). I'm not sure what problems this could lead to...it would certainly need to be tested. One could argue though that if you have security filters in place, you would'nt get that far anyway...and with acegi this is probably true. However with websphere 5.1, the user authentication is not (or doesn't appear to be) tied to the session (see below for explaination). I wouldn't say this is reason to avoid auto-creating the session...we just need to be aware of the possible side-effects. I haven't given Web Flow the full looking over yet so pardon me if this is a rediculous question, but is there anyway it can support flows without session (in-addition-to not instead-of)? Perhaps by passing the 'current-state' along with the request...and not allowing flow-scoped attributes in these cases? I imagine situations where it would be nice to define flows for visiting users...and not want to have a session created for all visitors. When using container managed security in WAS5.1, IF the 'logout' action simply invalidates the session, webshpere still thinks the user is authenticated (they have a magic ibm_security_logout uri that must be hit to clear the user authentication). I never tested what happens to the authenication info when a session-timeout occurs...and I don't have access to a 5.1 machine now...but if it does not become invalidated when the session does, then websphere would happily say: "hey, you're authenticated, come on in" and then the session will be created (empty) for the mid-flow request. This little change (didn't happen in 5.0..only 5.1) caused some grief on my last project. James On Thu, 31 Mar 2005 21:36:32 +0200, Erwin Vervaet <erw...@er...> wrote: > The Spring Web Flow (SWF) FlowController forces the "requireSession" > property it inherits from AbstractController to "true". This is logical > since the webflow system needs to store flow execution state in the HTTP > session. > > So far so good. However, since the controller now requires an existing > session, the user/developer is responsible for creating that session before > a flow is started. This is typically not a problem in real-life applications > since those carefully manage session creation and invalidation. > > Still, we are wondering whether it is a good idea to implicitly create > sessions (usually using request.getSession()) in a controller, or should > this be left as a responsability of the application developer? Note that > AbstractWizardFormController and AbstractFormController implicitly create > sessions. > > Erwin Vervaet > erw...@er... > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/info/Sentarus/hamr30 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Alef A. <al...@jt...> - 2005-03-31 21:44:10
|
It's what ASP.NET (and I think some JSF implementations) does as well - serialization of the state in a hidden input field. I don't think it'd be that difficult to implement a custom tag that does this, wouldn't it? rgds, Alef On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote: > I see no problem in implictly creating a session - although I am > concerned about the impact of this on clustered applications. Can the > session implementation be factored out so that users can implement > their own session storage? > > Rob > > Erwin Vervaet wrote: > >> The Spring Web Flow (SWF) FlowController forces the "requireSession" >> property it inherits from AbstractController to "true". This is >> logical since the webflow system needs to store flow execution state >> in the HTTP session. >> >> So far so good. However, since the controller now requires an >> existing session, the user/developer is responsible for creating that >> session before a flow is started. This is typically not a problem in >> real-life applications since those carefully manage session creation >> and invalidation. >> >> Still, we are wondering whether it is a good idea to implicitly >> create sessions (usually using request.getSession()) in a controller, >> or should this be left as a responsability of the application >> developer? Note that AbstractWizardFormController and >> AbstractFormController implicitly create sessions. >> >> Erwin Vervaet >> erw...@er... >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by Demarc: >> A global provider of Threat Management Solutions. >> Download our HomeAdmin security software for free today! >> http://www.demarc.com/info/Sentarus/hamr30 >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/info/Sentarus/hamr30 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Rob H. <ro...@ca...> - 2005-03-31 22:45:37
|
Indeed - I am actually doing this with a client at the moment. They have two separate geographic locations and a small amount of state to maintain, so we are going to encode it in hidden fields. Rob Alef Arendsen wrote: > It's what ASP.NET (and I think some JSF implementations) does as well > - serialization of the state in a hidden input field. I don't think > it'd be that difficult to implement a custom tag that does this, > wouldn't it? > > rgds, > Alef > > On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote: > >> I see no problem in implictly creating a session - although I am >> concerned about the impact of this on clustered applications. Can the >> session implementation be factored out so that users can implement >> their own session storage? >> >> Rob >> >> Erwin Vervaet wrote: >> >>> The Spring Web Flow (SWF) FlowController forces the "requireSession" >>> property it inherits from AbstractController to "true". This is >>> logical since the webflow system needs to store flow execution state >>> in the HTTP session. >>> >>> So far so good. However, since the controller now requires an >>> existing session, the user/developer is responsible for creating >>> that session before a flow is started. This is typically not a >>> problem in real-life applications since those carefully manage >>> session creation and invalidation. >>> >>> Still, we are wondering whether it is a good idea to implicitly >>> create sessions (usually using request.getSession()) in a >>> controller, or should this be left as a responsability of the >>> application developer? Note that AbstractWizardFormController and >>> AbstractFormController implicitly create sessions. >>> >>> Erwin Vervaet >>> erw...@er... >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by Demarc: >>> A global provider of Threat Management Solutions. >>> Download our HomeAdmin security software for free today! >>> http://www.demarc.com/info/Sentarus/hamr30 >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> >>> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by Demarc: >> A global provider of Threat Management Solutions. >> Download our HomeAdmin security software for free today! >> http://www.demarc.com/info/Sentarus/hamr30 >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/info/Sentarus/hamr30 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Keith D. <ke...@in...> - 2005-03-31 22:49:23
|
Just thinking out loud here, but no, I don't think this would be too difficult to implement. There is potentially lot to serialize out on each request, though, particularly if you a flow execution that has spawned many nested subflows. Methinks we could have custom tag that serializes the FlowExecutionStack on each request. This would include serializing: - The ID of the flow execution (randomly generated guid) - The stack of IDs of all spawned flows, the top being the active flow and the rest any suspended parent flows (if the active flow is a subflow) - For each flow in the stack, everything in 'flow scope'. This does introduce the issue of having to convert from string representations of objects in flow scope on each request, possibly applying automatic type conversion from attribute metadata (e.g from string -> number). Do you know how this issue is handled in ASP.NET and JSF? Currently FlowExecution storage responsibility is externalized from the core web.flow system -- the FlowExecutionStack, the central object for starting and manipulating a single client instance of a top-level flow, is a safely serializable memento. The HttpServletFlowExecutionManager, by default, uses HTTP session storage, but the get(..), save(..) and remove(...) methods that accomplish this could be overridden to serialize to some other place like a database. A custom HttpServletFlowExecutionManager subclass would likely need to be written to accomplish deserializing flow state in a hidden form back to a fully constructed FlowExecutionStack on each request. One issue is whether it makes sense to refactor this class given that need, and if so how. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Alef Arendsen Sent: Thursday, March 31, 2005 4:44 PM To: spr...@li... Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed It's what ASP.NET (and I think some JSF implementations) does as well - serialization of the state in a hidden input field. I don't think it'd be that difficult to implement a custom tag that does this, wouldn't it? rgds, Alef On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote: > I see no problem in implictly creating a session - although I am > concerned about the impact of this on clustered applications. Can the > session implementation be factored out so that users can implement > their own session storage? > > Rob > > Erwin Vervaet wrote: > >> The Spring Web Flow (SWF) FlowController forces the "requireSession" >> property it inherits from AbstractController to "true". This is >> logical since the webflow system needs to store flow execution state >> in the HTTP session. >> >> So far so good. However, since the controller now requires an >> existing session, the user/developer is responsible for creating that >> session before a flow is started. This is typically not a problem in >> real-life applications since those carefully manage session creation >> and invalidation. >> >> Still, we are wondering whether it is a good idea to implicitly >> create sessions (usually using request.getSession()) in a controller, >> or should this be left as a responsability of the application >> developer? Note that AbstractWizardFormController and >> AbstractFormController implicitly create sessions. >> >> Erwin Vervaet >> erw...@er... >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by Demarc: >> A global provider of Threat Management Solutions. >> Download our HomeAdmin security software for free today! >> http://www.demarc.com/info/Sentarus/hamr30 >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/info/Sentarus/hamr30 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Seth L. <set...@gm...> - 2005-03-31 23:21:33
|
On Thu, 31 Mar 2005 17:49:24 -0500, Keith Donald <ke...@in...> wrote: > Just thinking out loud here, but no, I don't think this would be too > difficult to implement. There is potentially lot to serialize out on each > request, though, particularly if you a flow execution that has spawned many > nested subflows. > > Methinks we could have custom tag that serializes the FlowExecutionStack on > each request. This would include serializing: > - The ID of the flow execution (randomly generated guid) > - The stack of IDs of all spawned flows, the top being the active flow and > the rest any suspended parent flows (if the active flow is a subflow) > - For each flow in the stack, everything in 'flow scope'. Keith, Sounds like there might be two Strategies here for storing the FlowExecutionStack: HttpSession Strategy and HttpRequest Strategy. The developer can then choose the strategy for their needs, as there are good use cases for not requiring a session. Seth |
|
From: Keith D. <ke...@in...> - 2005-04-01 00:46:57
|
Seth,
Excellent idea.
If we extract an interface from the HttpServletExecutionManager, we get
something like:
public interface FlowExecutionStorage {
public FlowExecution loadFrom(Event inputEvent);
public void saveOrUpdate(FlowExecution flowExecution);
public void remove(FlowExecution flowExecution);
}
Or something like that. Erwin what do you think? Need to think about it
more. I imagine here the FlowExecutionStack would have to be reconstructed
from the Event parameters, for example: http request parameters, in an http
servlet environment. It also has to be rehydrated with services on
deserialization as well, including the FlowLocator and its
FlowExecutionListenerList.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: Thursday, March 31, 2005 6:21 PM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed
On Thu, 31 Mar 2005 17:49:24 -0500, Keith Donald <ke...@in...>
wrote:
> Just thinking out loud here, but no, I don't think this would be too
> difficult to implement. There is potentially lot to serialize out on each
> request, though, particularly if you a flow execution that has spawned
many
> nested subflows.
>
> Methinks we could have custom tag that serializes the FlowExecutionStack
on
> each request. This would include serializing:
> - The ID of the flow execution (randomly generated guid)
> - The stack of IDs of all spawned flows, the top being the active flow and
> the rest any suspended parent flows (if the active flow is a subflow)
> - For each flow in the stack, everything in 'flow scope'.
Keith,
Sounds like there might be two Strategies here for storing the
FlowExecutionStack: HttpSession Strategy and HttpRequest Strategy.
The developer can then choose the strategy for their needs, as there
are good use cases for not requiring a session.
Seth
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Seth L. <set...@gm...> - 2005-04-01 00:55:58
|
On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...> wrote:
> Seth,
>
> Excellent idea.
>
> If we extract an interface from the HttpServletExecutionManager, we get
> something like:
>
> public interface FlowExecutionStorage {
> public FlowExecution loadFrom(Event inputEvent);
> public void saveOrUpdate(FlowExecution flowExecution);
> public void remove(FlowExecution flowExecution);
> }
>
> Or something like that. Erwin what do you think? Need to think about it
> more. I imagine here the FlowExecutionStack would have to be reconstructed
> from the Event parameters, for example: http request parameters, in an http
> servlet environment. It also has to be rehydrated with services on
> deserialization as well, including the FlowLocator and its
> FlowExecutionListenerList.
Keith,
Just so I'm clear... this isn't to replace the concept and purpose of
the HttpSession? This is just to provide a way to get the state info
of the flow into the request to avoid the need for session creation?
Thanks!
Seth
|
|
From: Keith D. <ke...@in...> - 2005-04-01 01:46:36
|
Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
HttpRequestFlowExecutionStorage would use the request, for example. The
latter would also have to know how to reconstruct the FlowExecution soley
from the request parameters, while the former would just pull an existing
instance from the HttpSession given the flowExecutionId in the input Event.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: Thursday, March 31, 2005 7:56 PM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed
On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
wrote:
> Seth,
>
> Excellent idea.
>
> If we extract an interface from the HttpServletExecutionManager, we get
> something like:
>
> public interface FlowExecutionStorage {
> public FlowExecution loadFrom(Event inputEvent);
> public void saveOrUpdate(FlowExecution flowExecution);
> public void remove(FlowExecution flowExecution);
> }
>
> Or something like that. Erwin what do you think? Need to think about it
> more. I imagine here the FlowExecutionStack would have to be
reconstructed
> from the Event parameters, for example: http request parameters, in an
http
> servlet environment. It also has to be rehydrated with services on
> deserialization as well, including the FlowLocator and its
> FlowExecutionListenerList.
Keith,
Just so I'm clear... this isn't to replace the concept and purpose of
the HttpSession? This is just to provide a way to get the state info
of the flow into the request to avoid the need for session creation?
Thanks!
Seth
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Rob H. <ro...@ca...> - 2005-04-01 09:00:33
|
What about scoping - how will this be handled by the storage interface?
Rob
Keith Donald wrote:
>Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
>HttpRequestFlowExecutionStorage would use the request, for example. The
>latter would also have to know how to reconstruct the FlowExecution soley
>from the request parameters, while the former would just pull an existing
>instance from the HttpSession given the flowExecutionId in the input Event.
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Seth Ladd
>Sent: Thursday, March 31, 2005 7:56 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>Feedback needed
>
>On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
>wrote:
>
>
>>Seth,
>>
>>Excellent idea.
>>
>>If we extract an interface from the HttpServletExecutionManager, we get
>>something like:
>>
>>public interface FlowExecutionStorage {
>> public FlowExecution loadFrom(Event inputEvent);
>> public void saveOrUpdate(FlowExecution flowExecution);
>> public void remove(FlowExecution flowExecution);
>>}
>>
>>Or something like that. Erwin what do you think? Need to think about it
>>more. I imagine here the FlowExecutionStack would have to be
>>
>>
>reconstructed
>
>
>>from the Event parameters, for example: http request parameters, in an
>>
>>
>http
>
>
>>servlet environment. It also has to be rehydrated with services on
>>deserialization as well, including the FlowLocator and its
>>FlowExecutionListenerList.
>>
>>
>
>
>Keith,
>
>Just so I'm clear... this isn't to replace the concept and purpose of
>the HttpSession? This is just to provide a way to get the state info
>of the flow into the request to avoid the need for session creation?
>
>Thanks!
>Seth
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
|
|
From: James E. <jam...@gm...> - 2005-04-01 12:16:28
|
What about an implementation that would 'do what is best'. Save to
the session if it already exists, serialize to the request if not.
Then have a custom tag to spit out the flow info in the form. The tag
would pull the serialized flow info from the request (if it exists)
and add a new hidden input field for it (_flowInstance or
something)...otherwise if a session exists and the info is on the
session it would spit out what is expected now (the _* hidden fields).
At the beginning of a request, it would look to see if the serialized
param (_flowInstance) is on the request first...if so, deserialize.
If not, see if a session exists and pull from the session using _*
params.
If you have a truly complex object graph, set a 'requiresSession'
boolean to true (defaults to false)...although I would think it best
to try and keep it as simple as possible when going in the session.
With this approach your not doing more than you need (when a session
does exist), and (as a bonus) you can have flows that are used by
non-session visitors and with-session users, and the impl would 'do
what is best' in both situations.
James
On Apr 1, 2005 3:00 AM, Rob Harrop <ro...@ca...> wrote:
> What about scoping - how will this be handled by the storage interface?
>
> Rob
>
> Keith Donald wrote:
>
> >Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
> >HttpRequestFlowExecutionStorage would use the request, for example. The
> >latter would also have to know how to reconstruct the FlowExecution soley
> >from the request parameters, while the former would just pull an existing
> >instance from the HttpSession given the flowExecutionId in the input Event.
> >
> >Keith
> >
> >-----Original Message-----
> >From: spr...@li...
> >[mailto:spr...@li...] On Behalf Of
> >Seth Ladd
> >Sent: Thursday, March 31, 2005 7:56 PM
> >To: spr...@li...
> >Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
> >Feedback needed
> >
> >On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
> >wrote:
> >
> >
> >>Seth,
> >>
> >>Excellent idea.
> >>
> >>If we extract an interface from the HttpServletExecutionManager, we get
> >>something like:
> >>
> >>public interface FlowExecutionStorage {
> >> public FlowExecution loadFrom(Event inputEvent);
> >> public void saveOrUpdate(FlowExecution flowExecution);
> >> public void remove(FlowExecution flowExecution);
> >>}
> >>
> >>Or something like that. Erwin what do you think? Need to think about it
> >>more. I imagine here the FlowExecutionStack would have to be
> >>
> >>
> >reconstructed
> >
> >
> >>from the Event parameters, for example: http request parameters, in an
> >>
> >>
> >http
> >
> >
> >>servlet environment. It also has to be rehydrated with services on
> >>deserialization as well, including the FlowLocator and its
> >>FlowExecutionListenerList.
> >>
> >>
> >
> >
> >Keith,
> >
> >Just so I'm clear... this isn't to replace the concept and purpose of
> >the HttpSession? This is just to provide a way to get the state info
> >of the flow into the request to avoid the need for session creation?
> >
> >Thanks!
> >Seth
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by Demarc:
> >A global provider of Threat Management Solutions.
> >Download our HomeAdmin security software for free today!
> >http://www.demarc.com/info/Sentarus/hamr30
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by Demarc:
> >A global provider of Threat Management Solutions.
> >Download our HomeAdmin security software for free today!
> >http://www.demarc.com/info/Sentarus/hamr30
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: James E. <jam...@gm...> - 2005-04-01 15:59:34
|
Not sure why this didn't come through...size? I see it and another post from Rob in the archive...just never got them (checked another developer too). If this is a duplicate for some, I apologize. ----- What about an implementation that would 'do what is best'. Save to the session if it already exists, serialize to the request if not. Then have a custom tag to spit out the flow info in the form. The tag would pull the serialized flow info from the request (if it exists) and add a new hidden input field for it (_flowInstance or something)...otherwise if a session exists and the info is on the session it would spit out what is expected now (the _* hidden fields). At the beginning of a request, it would look to see if the serialized param (_flowInstance) is on the request first...if so, deserialize. If not, see if a session exists and pull from the session using _* params. If you have a truly complex object graph, set a 'requiresSession' boolean to true (defaults to false)...although I would think it best to try and keep it as simple as possible when going in the session. With this approach your not doing more than you need (when a session does exist), and (as a bonus) you can have flows that are used by non-session visitors and with-session users, and the impl would 'do what is best' in both situations. James |
|
From: Erwin V. <erw...@er...> - 2005-04-02 17:27:52
|
> What about an implementation that would 'do what is best'. Save to > the session if it already exists, serialize to the request if not. > Then have a custom tag to spit out the flow info in the form. The tag > would pull the serialized flow info from the request (if it exists) > and add a new hidden input field for it (_flowInstance or > something)...otherwise if a session exists and the info is on the > session it would spit out what is expected now (the _* hidden fields). > At the beginning of a request, it would look to see if the serialized > param (_flowInstance) is on the request first...if so, deserialize. > If not, see if a session exists and pull from the session using _* > params. Interesting idea to have it automatically select request or session based storage. I added pluggable FlowExecutionStorage strategies this morning so this would be trivial to do. Also, I implemented a "client side flow execution" storage strategy and it is just encoding the entire flow execution in the flowExecutionId. No need for any special handling in the views, the storage strategy is completely pluggable! > If you have a truly complex object graph, set a 'requiresSession' > boolean to true (defaults to false)...although I would think it best > to try and keep it as simple as possible when going in the session. > > With this approach your not doing more than you need (when a session > does exist), and (as a bonus) you can have flows that are used by > non-session visitors and with-session users, and the impl would 'do > what is best' in both situations. Yep, nice! I'm sure Keith is gonna blog about it, but <gavingKingMode> our new pluggable flow execution storage strategies kick some serious butt! </gavingKingMode> :) |
|
From: Keith D. <ke...@in...> - 2005-04-01 13:05:30
|
What do you mean exactly? If you mean getting/putting data in different
scopes, that's handled by another object: the RequestContext. There is a
request Scope (requestContext.getRequestScope()) and a flow Scope
(requestContext.getFlowScope()). Ultimately, hidden from the user of
course, Flow scope data gets managed in the active FlowSession object, which
is at the top of the FlowExecutionStack, which is serializable.
Is this what you wanted to hear? :-)
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rob Harrop
Sent: Friday, April 01, 2005 4:01 AM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed
What about scoping - how will this be handled by the storage interface?
Rob
Keith Donald wrote:
>Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
>HttpRequestFlowExecutionStorage would use the request, for example. The
>latter would also have to know how to reconstruct the FlowExecution soley
>from the request parameters, while the former would just pull an existing
>instance from the HttpSession given the flowExecutionId in the input Event.
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Seth Ladd
>Sent: Thursday, March 31, 2005 7:56 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>Feedback needed
>
>On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
>wrote:
>
>
>>Seth,
>>
>>Excellent idea.
>>
>>If we extract an interface from the HttpServletExecutionManager, we get
>>something like:
>>
>>public interface FlowExecutionStorage {
>> public FlowExecution loadFrom(Event inputEvent);
>> public void saveOrUpdate(FlowExecution flowExecution);
>> public void remove(FlowExecution flowExecution);
>>}
>>
>>Or something like that. Erwin what do you think? Need to think about it
>>more. I imagine here the FlowExecutionStack would have to be
>>
>>
>reconstructed
>
>
>>from the Event parameters, for example: http request parameters, in an
>>
>>
>http
>
>
>>servlet environment. It also has to be rehydrated with services on
>>deserialization as well, including the FlowLocator and its
>>FlowExecutionListenerList.
>>
>>
>
>
>Keith,
>
>Just so I'm clear... this isn't to replace the concept and purpose of
>the HttpSession? This is just to provide a way to get the state info
>of the flow into the request to avoid the need for session creation?
>
>Thanks!
>Seth
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Erwin V. <erw...@er...> - 2005-04-02 17:21:16
|
The storage interface doesn't need to worry about scoping: it only needs to
deal with flow scope. Request scope and event scope never outlive the
current request.
Erwin Vervaet
----- Original Message -----
From: "Rob Harrop" <ro...@ca...>
To: <spr...@li...>
Sent: Friday, April 01, 2005 11:00 AM
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed
> What about scoping - how will this be handled by the storage interface?
>
> Rob
>
> Keith Donald wrote:
>
>>Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
>>HttpRequestFlowExecutionStorage would use the request, for example. The
>>latter would also have to know how to reconstruct the FlowExecution soley
>>from the request parameters, while the former would just pull an existing
>>instance from the HttpSession given the flowExecutionId in the input
>>Event.
>>
>>Keith
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf
>>Of
>>Seth Ladd
>>Sent: Thursday, March 31, 2005 7:56 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>>Feedback needed
>>
>>On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
>>wrote:
>>
>>>Seth,
>>>
>>>Excellent idea.
>>>
>>>If we extract an interface from the HttpServletExecutionManager, we get
>>>something like:
>>>
>>>public interface FlowExecutionStorage {
>>> public FlowExecution loadFrom(Event inputEvent);
>>> public void saveOrUpdate(FlowExecution flowExecution);
>>> public void remove(FlowExecution flowExecution);
>>>}
>>>
>>>Or something like that. Erwin what do you think? Need to think about it
>>>more. I imagine here the FlowExecutionStack would have to be
>>>
>>reconstructed
>>
>>>from the Event parameters, for example: http request parameters, in an
>>>
>>http
>>
>>>servlet environment. It also has to be rehydrated with services on
>>>deserialization as well, including the FlowLocator and its
>>>FlowExecutionListenerList.
>>>
>>
>>
>>Keith,
>>
>>Just so I'm clear... this isn't to replace the concept and purpose of
>>the HttpSession? This is just to provide a way to get the state info
>>of the flow into the request to avoid the need for session creation?
>>
>>Thanks!
>>Seth
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by Demarc:
>>A global provider of Threat Management Solutions.
>>Download our HomeAdmin security software for free today!
>>http://www.demarc.com/info/Sentarus/hamr30
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by Demarc:
>>A global provider of Threat Management Solutions.
>>Download our HomeAdmin security software for free today!
>>http://www.demarc.com/info/Sentarus/hamr30
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Erwin V. <erw...@er...> - 2005-04-01 06:10:06
|
+1
We'll have to look into how difficult this would be to implement.
Storing the flow execution state in the request could also make web flows
usable in situations
where you have back-button/refresh-button issues.
This would also allow us to implement a "continuation like" flow execution
system: clone the
flow execution for every request, generate a unique id for each clone and
put that id in the request and
the flow execution clone is some storage somewhere. That way the flow
execution effectively
becomes a continuation! This would also solve most
back-button/refresh-button issues, but
is ofcourse memory intensive.
Erwin Vervaet
erw...@er...
----- Original Message -----
From: "Keith Donald" <ke...@in...>
To: <spr...@li...>
Sent: Friday, April 01, 2005 2:46 AM
Subject: RE: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed
> Seth,
>
> Excellent idea.
>
> If we extract an interface from the HttpServletExecutionManager, we get
> something like:
>
> public interface FlowExecutionStorage {
> public FlowExecution loadFrom(Event inputEvent);
> public void saveOrUpdate(FlowExecution flowExecution);
> public void remove(FlowExecution flowExecution);
> }
>
> Or something like that. Erwin what do you think? Need to think about it
> more. I imagine here the FlowExecutionStack would have to be
> reconstructed
> from the Event parameters, for example: http request parameters, in an
> http
> servlet environment. It also has to be rehydrated with services on
> deserialization as well, including the FlowLocator and its
> FlowExecutionListenerList.
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of
> Seth Ladd
> Sent: Thursday, March 31, 2005 6:21 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
> Feedback needed
>
> On Thu, 31 Mar 2005 17:49:24 -0500, Keith Donald <ke...@in...>
> wrote:
>> Just thinking out loud here, but no, I don't think this would be too
>> difficult to implement. There is potentially lot to serialize out on
>> each
>> request, though, particularly if you a flow execution that has spawned
> many
>> nested subflows.
>>
>> Methinks we could have custom tag that serializes the FlowExecutionStack
> on
>> each request. This would include serializing:
>> - The ID of the flow execution (randomly generated guid)
>> - The stack of IDs of all spawned flows, the top being the active flow
>> and
>> the rest any suspended parent flows (if the active flow is a subflow)
>> - For each flow in the stack, everything in 'flow scope'.
>
> Keith,
>
> Sounds like there might be two Strategies here for storing the
> FlowExecutionStack: HttpSession Strategy and HttpRequest Strategy.
> The developer can then choose the strategy for their needs, as there
> are good use cases for not requiring a session.
>
> Seth
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
|
|
From: J. E. R. <er...@di...> - 2005-04-01 08:26:24
|
Hi all,
We think it is a great idea that contributes to do SWF more independent
from
the framework used, Portlets, Struts, etc.
The biggest problem that we have encountered to use a unique
FlowExecutionManager
from Spring PortletMVC has been the manner to store/load the FlowExecution.
With this new interface should be easy to implement an
AbstractFlowExecutionManager, or a FlowExecutionManager that delegates on
FlowExecutionStorage strategy (depends on the design pattern used).
Regards.
> +1
>
> We'll have to look into how difficult this would be to implement.
>
> Storing the flow execution state in the request could also make web
> flows usable in situations
> where you have back-button/refresh-button issues.
>
> This would also allow us to implement a "continuation like" flow
> execution system: clone the
> flow execution for every request, generate a unique id for each clone
> and put that id in the request and
> the flow execution clone is some storage somewhere. That way the flow
> execution effectively
> becomes a continuation! This would also solve most
> back-button/refresh-button issues, but
> is ofcourse memory intensive.
>
> Erwin Vervaet
> erw...@er...
> ----- Original Message ----- From: "Keith Donald" <ke...@in...>
> To: <spr...@li...>
> Sent: Friday, April 01, 2005 2:46 AM
> Subject: RE: [Springframework-developer] SWF - Creating HTTP sessions
> - Feedback needed
>
>
>> Seth,
>>
>> Excellent idea.
>>
>> If we extract an interface from the HttpServletExecutionManager, we get
>> something like:
>>
>> public interface FlowExecutionStorage {
>> public FlowExecution loadFrom(Event inputEvent);
>> public void saveOrUpdate(FlowExecution flowExecution);
>> public void remove(FlowExecution flowExecution);
>> }
>>
>> Or something like that. Erwin what do you think? Need to think about it
>> more. I imagine here the FlowExecutionStack would have to be
>> reconstructed
>> from the Event parameters, for example: http request parameters, in
>> an http
>> servlet environment. It also has to be rehydrated with services on
>> deserialization as well, including the FlowLocator and its
>> FlowExecutionListenerList.
>>
>> Keith
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On
>> Behalf Of
>> Seth Ladd
>> Sent: Thursday, March 31, 2005 6:21 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>> Feedback needed
>>
>> On Thu, 31 Mar 2005 17:49:24 -0500, Keith Donald <ke...@in...>
>> wrote:
>>
>>> Just thinking out loud here, but no, I don't think this would be too
>>> difficult to implement. There is potentially lot to serialize out
>>> on each
>>> request, though, particularly if you a flow execution that has spawned
>>
>> many
>>
>>> nested subflows.
>>>
>>> Methinks we could have custom tag that serializes the
>>> FlowExecutionStack
>>
>> on
>>
>>> each request. This would include serializing:
>>> - The ID of the flow execution (randomly generated guid)
>>> - The stack of IDs of all spawned flows, the top being the active
>>> flow and
>>> the rest any suspended parent flows (if the active flow is a subflow)
>>> - For each flow in the stack, everything in 'flow scope'.
>>
>>
>> Keith,
>>
>> Sounds like there might be two Strategies here for storing the
>> FlowExecutionStack: HttpSession Strategy and HttpRequest Strategy.
>> The developer can then choose the strategy for their needs, as there
>> are good use cases for not requiring a session.
>>
>> Seth
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
--
J.Enrique Ruiz
Director de I+D+I - DiSiD S.L.L. (http://www.disid.com)
Tel +34 655 407 965
Email: er...@di...
|
|
From: Colin S. <col...@ex...> - 2005-04-01 20:12:42
|
Tapestry 3.1/4.0 (the current CVS version of Tapestry) also makes this pluggable... Storing page state in the Session is just the default. Alef Arendsen wrote: > It's what ASP.NET (and I think some JSF implementations) does as well > - serialization of the state in a hidden input field. I don't think > it'd be that difficult to implement a custom tag that does this, > wouldn't it? > > rgds, > Alef > > On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote: > >> I see no problem in implictly creating a session - although I am >> concerned about the impact of this on clustered applications. Can the >> session implementation be factored out so that users can implement >> their own session storage? >> >> Rob >> >> Erwin Vervaet wrote: >> >>> The Spring Web Flow (SWF) FlowController forces the "requireSession" >>> property it inherits from AbstractController to "true". This is >>> logical since the webflow system needs to store flow execution state >>> in the HTTP session. >>> >>> So far so good. However, since the controller now requires an >>> existing session, the user/developer is responsible for creating >>> that session before a flow is started. This is typically not a >>> problem in real-life applications since those carefully manage >>> session creation and invalidation. >>> >>> Still, we are wondering whether it is a good idea to implicitly >>> create sessions (usually using request.getSession()) in a >>> controller, or should this be left as a responsability of the >>> application developer? Note that AbstractWizardFormController and >>> AbstractFormController implicitly create sessions. >>> >>> Erwin Vervaet >>> erw...@er... >> |
|
From: Erwin V. <erw...@er...> - 2005-04-02 17:31:35
|
As I mentioned in previous posts, we've now got a pluggable FlowExecutionStorage strategies so we basically have all options open now. I set it up in such a way that we don't even need any special handling in the view (via a custom tag or so): the storage strategy is completely pluggable: you could switch from service side to client side storage without even affecting your views (JSPs), just by doing a bit of config in your application context! Erwin Vervaet erw...@er... ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: <spr...@li...> Sent: Friday, April 01, 2005 10:12 PM Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed > Tapestry 3.1/4.0 (the current CVS version of Tapestry) also makes this > pluggable... Storing page state in the Session is just the default. > > Alef Arendsen wrote: > >> It's what ASP.NET (and I think some JSF implementations) does as well - >> serialization of the state in a hidden input field. I don't think it'd be >> that difficult to implement a custom tag that does this, wouldn't it? >> >> rgds, >> Alef >> >> On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote: >> >>> I see no problem in implictly creating a session - although I am >>> concerned about the impact of this on clustered applications. Can the >>> session implementation be factored out so that users can implement their >>> own session storage? >>> >>> Rob >>> >>> Erwin Vervaet wrote: >>> >>>> The Spring Web Flow (SWF) FlowController forces the "requireSession" >>>> property it inherits from AbstractController to "true". This is logical >>>> since the webflow system needs to store flow execution state in the >>>> HTTP session. >>>> >>>> So far so good. However, since the controller now requires an existing >>>> session, the user/developer is responsible for creating that session >>>> before a flow is started. This is typically not a problem in real-life >>>> applications since those carefully manage session creation and >>>> invalidation. >>>> >>>> Still, we are wondering whether it is a good idea to implicitly create >>>> sessions (usually using request.getSession()) in a controller, or >>>> should this be left as a responsability of the application developer? >>>> Note that AbstractWizardFormController and AbstractFormController >>>> implicitly create sessions. >>>> >>>> Erwin Vervaet >>>> erw...@er... >>> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
