Thanks for the ideas, Thomas.
Two questions on the response:
1. I was hoping to detect this within my service method, rather than
at a higher level like a servlet filter. Is it possible to return a
non-200 error code from within the service method? I tried getting
the thread local HttpResponse object and changing its status code, but
this had no effect.
2. If I do write a servlet filter, there are only certain service
methods that I want this code to apply to (for example, I use a
service method, rather than the built in servlet authentication to
authenticate the user, and I certainly don't want to require a valid
session during this call). From what I see in the sample code you
posted, it looks like that application is doing this on every
request. What is the best way to differentiate which service
method(s) are being called as part of the request? Are there classes
available that will help me parse the request payload on the server
and identify the methods being called?
Ryan
On Jun 5, 5:21 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> On Monday, June 4, 2012 10:17:52 PM UTC+2, Ryan McFall wrote:
>
> > I am having issues when I want to resubmit some requests to the server
> > when the server-side logic indicates it should happen. In particular,
> > here's what happens:
>
> > 1. The user logins in, which causes an object (SurveyResponseHeader)
> > to be created on the server-side, and sent back to the client. edit
> > is then called on the client side on that object.
>
> > 2. The user fills in a set of SurveyResponse objects into a list
> > contained by the SurveyResponseHeader object (and a corresponding
> > request is made to save the object on the server).
>
> > 3. The user submits the survey responses, but the session has timed
> > out on the server. An error code is sent back to the client, and the
> > user is asked to re-authenticate.
>
> > At this point, I want to resubmit the request that caused the error;
> > it should succeed on the server now because the session has been
> > restarted. However, I can't use the same request object because I'll
> > get the "request is already in progress" error message.
>
> > Rather than tell you everything I've tried, I'd like to hear what
> > people think is the right way to accomplish this. I can provide more
> > details if needed, but I want to keep the description simple at least
> > to start.
>
> You have to make sure you convey the session-expiry-error as a "transport
> error" or "general failure", and not as a "service method return value".
> Using the DefaultRequestTransport, any non-200 response from the server
> will be a "transport error", so handling session expiration from a servlet
> filter on the server and responding with a non-200 status code (let's say,
> for instance, a 401, or 400; make sure you don't redirect to your login
> page though!) should Just Work(tm).
> To tell the difference between a real server failure and session expiration
> though, you'll have to make your own RequestTransport on the client
> (possibly extending DefaultRequestTransport) and define some kind of
> "protocol" (shared knowledge) with the server. Have a look at how it's done
> in the MobileWebApp sample in the GWT SDK:http://code.google.com/p/google-web-toolkit/source/browse/trunk/sampl...It's
> specific to Google AppEngine but is really easy to adapt to whatever you
> use. The trick is to make sure you don't set a <security-constraint> on the
> RequestFactoryServlet in your web.xml, and instead handle the absence of
> authenticated user from code (in a servlet filter is the easiest)
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment