Re: Execute and wait interceptor and calling an action more than once

2008-07-22 Thread Jeromy Evans
Burak Doğruöz wrote: I don't think that it can be done with an ajax approach. With ajax or not, concurrent requests for the same action name returns first action's result. I tried this simple scenario with an action which outputs its query parameter. I also added a thread.sleep in execute

Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Burak Doğruöz
Hi, Our application lets user to run 2 (or more) copies of same action at the same time (possibly with different parameters) in a frameset. In execute and wait interceptor documentation ( http://struts.apache.org/2.x/docs/execute-and-wait-interceptor.html), it says that execute and wait

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Jeromy Evans
Burak Doğruöz wrote: Hi, Our application lets user to run 2 (or more) copies of same action at the same time (possibly with different parameters) in a frameset. In execute and wait interceptor documentation ( http://struts.apache.org/2.x/docs/execute-and-wait-interceptor.html), it says that

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Giovanni Azua
hi, I think that actually you can run more than one execAndWait at the time for the same Session, the problem though is that you have no guarantee on which result will be returned to which browser e.g. Session 1 - browser 1 - triggers execAndWait = gets result of action triggered by Browser

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Burak Doğruöz
Thanks for your response, I think, even with an ajax approach, concurrent requests for same action would result in unexpected output as these actions are stored by same action name at background. So in fact this is not a presentation constraint but a processing constraint. We can neither prevent

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Jeromy Evans
Burak Doğruöz wrote: Thanks for your response, I think, even with an ajax approach, concurrent requests for same action would result in unexpected output as these actions are stored by same action name at background. So in fact this is not a presentation constraint but a processing constraint.

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Dave Newton
--- On Mon, 7/21/08, Burak Doğruöz wrote: I think, even with an ajax approach, concurrent requests for same action would result in unexpected output as these actions are stored by same action name at background. Each request would get its own action instance. The DOM element being updated is

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Burak Doğruöz
So, how to override this ExecAndWiatInterceptor behaviour? Is it possible to map by some key other than action name? If we use wildcards while defining action mapping, can we bypass this constraint? This way we can call myAction1, myAction2 and myActionRandomN which trigger myAction.action. Does

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Burak Doğruöz
The constraint here is about ExecAndWaitInterceptor storing and returning multiple copies of one certain action. This constraint is already in the documentation. We are looking for a turn around. For example if we open 2 browsers (which share the same session) and call same action (which has

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Dave Newton
--- On Mon, 7/21/08, Burak Doğruöz wrote: The constraint here is about ExecAndWaitInterceptor storing and returning multiple copies of one certain action. This constraint is already in the documentation. We are looking for a turn around. I was referring to the better solution, Jeremy's Ajax

Re: Execute and wait interceptor and calling an action more than once

2008-07-21 Thread Burak Doğruöz
I don't think that it can be done with an ajax approach. With ajax or not, concurrent requests for the same action name returns first action's result. I tried this simple scenario with an action which outputs its query parameter. I also added a thread.sleep in execute method to gain extra time to