Losing token in PRG pattern and please wait page

I'm having trouble implementing a PleaseWait page using Struts 1.3.10.

I have an SetupAction that calls saveToken(request) then displays a userEntry.jsp (using GET). I can see the TOKEN in the page source. I then POST to an action that checks the token, redirects to a PleaseWait page. This PleaseWait page then Meta refreshes to the actual ProcessOrderAction which takes a while.

Looks like this:

SetupAction --> saveToken(req) --> userEntry.jsp (GET)
UserEntry.jsp --> POSTs to --> PleaseWaitAction --> pleaseWait.jsp (GET)--> META REFRESH --> ProcessOrderAction

I can see the token (on the page source) up to the PleaseWaitAction, but I seem to lose the token when I go to the ProcessOrderAction.

Three questions:

where in the request do I look for the token? I use eclipse' debugger, and I've tried looking through all the request parameters. I can't find it. I find the token in the session, but not the request. Is it in the POST data? if so, how do I decipher it?

What can I do to get my ProcessOrderAction to see the token in the request?

Is there an easier way to handle long-running actions that can't be split up? Note that I'm stuck with an older version of struts

I've also tried extending the request processor to a LongWaitRequestProcessor, but I ran into the same problem. If I add the session token to the queryString on the pleaseWait.jsp , I can pass the token, but then the downstram TOKEN check never fails-- that is, I always seem to have a valid token.

Where am I going wrong and how can I find the TOKEN in the post data to help me debug this?

Here's where you might find a hint as to the internal workings of the Struts Token: http://stackoverflow.com/questions/1475061/struts-synchronizer-token

However, accessing the token by any means other than the methods that Struts already provides is a smell. The mechanism for handling the token was purposely abstracted away so that you, the developer, only had to worry about actually USING it for its intended purposes. This includes checking/preventing multiple submits and preventing a browser "page refresh" causing unwanted duplicate processing of requests. Why do you feel you need to get intimate with the Token itself?

Thanks, and I did see that post. Honestly, I **DON'T** want to get intimate with the Token, and in fact, I do use the form tag.

All I want is to get a pleaseWait page to work, but I keep losing the token in the Meta refresh.

The best I can do is to show a pleaseWait page with an action that checks the token (works here), and then call another action that takes a while with the meta tag. Trouble is, I check the token in the downstream action too and it always fails. The token in the request is null, but the one in the session is fine . So, I figured I ought to pass the token by doing a bit of URL rewriting in the META tag, but this isn't very elegant IMHO.

Open to other suggestions ... tried the longWaitRequestProcessor, but it uses the same META refresh approach. There is the servlet approach, but this requires hard-coding of html and more lower-level coding that at the level of actions. Not against it, but looking for something reproducible, other than moving to Struts2 or other framework. LongWaitRequestProcessor was a good option.

_R

The first thing that comes to my mind is AJAX.

User submits request --> Action hands off to Job Handler (POJO) --> Job Handler generates a JobID (your token) --> Kicks off asynchronous job process in something like Quartz --> hands JobId back to Action --> Action forwards to "Please Wait page" which has JavaScript, JobId is embedded in the JavaScript by JSP. When the Please Wait page is displayed, AJAX will periodically hit another Action, passing in the JobID. That Action will check the status of the asynch job process and return JSON to the AJAX caller to indicate done or not done. When AJAX call comes back with Done, make another AJAX call to bring up the appropriate results page.

This should work with older versions of Struts because the framework doesn't really care how the requests are submitted.

Yes, I think that's the way to do it. It's relatively independent, and scales well, even if I move to later versions / frameworks.

thanks!

_R