How are you exposing the REST call? A Servlet? Throwing a error in this case should trickle up to a HTTP code in the headers somehow, right? The AMF goodness handles this, encapsulates it, for you thus a error thrown in a RemoteObject call trickles up and all. But HTTPService may need more there by returning a particular HTTP status cod. Another approach is to return a standard HTTP response with erro info in the body. Your resultHamdler parses the response and decides to continue or call the faultHandler() if need be. I've had to do this with WebServices before with a client.
HTH! Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Fri, Aug 21, 2009 at 5:01 PM, Dale Bronk <[email protected]> wrote: > I had thought about it, but I really don’t like the idea of managing > session timeout on the client and the server. That is a server job and no > matter how careful you are, it is bound to get out of sync. Also, our app > will change the session timeout depending on the time of day and that would > mean then having to manage that on the client as well. I’m really very > shocked that my exception is getting eaten somewhere and not being brought > back to me. This tells me that if you do HTTPService then fault handling is > useless as you will never know what happened. Right now I’m going down the > path of creating a servlet filter that will hopefully be able to change the > http status code and use that. I’ll let you know if it works. Of course it > is a java solution. > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *eric > decoff > *Sent:* Friday, August 21, 2009 4:36 PM > > *To:* [email protected] > *Subject:* Re: [AFFUG Discuss] Session timeout > > > > Hey Dale, > > > > You might want to consider using a timer > > > > I put a sample of what I am talking about on my new blog > > > > http://ericdecoff.blogspot.com > > > > > > > > > > On Fri, Aug 21, 2009 at 1:26 PM, Dale Bronk <[email protected]> wrote: > > I have looked via debugger and basically expanded every piece of data. I > will look at the codes closer though. I gave them a look the first time, > but didn’t seem to be any different from any other fault. But a second look > certainly is not going to hurt. > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Marty > Blood > *Sent:* Friday, August 21, 2009 1:15 PM > > > *To:* [email protected] > *Subject:* Re: [AFFUG Discuss] Session timeout > > > > Have you tried running in debug and inspecting the FaultEvent manually? > Since it's a HTTPService call it might return a FaultEvent with a > HTTPResponse code (instead of a 200 maybe something more meaningful) or some > such that's populated differently than the AMF call. > > Looking at the FaultEvent API you might look at the statusCode field or the > content Object in the FaultEvent's Fault object to see if it has the > HTTPResponse data you need to see that it was a session timeout (or if it > was an exception the 500 or whatever server error response is coming back > down the pipe). There's also the headers Object on the FaultEvent and the > ErrorMessage which might contain the data you need. > > If you're feeling really fancy you can use WebScarab or some such to > intercept the HTTPService response and inspect the HTTP headers manually to > see if those give you any more insight. > > Anyway, good luck with that. > > -Marty > > On Fri, Aug 21, 2009 at 12:53 PM, Dale Bronk <[email protected]> wrote: > > Right, I'm not trying to catch it on the client. The server is catching it > and throwing an exception as per our design. That causes a FaultEvent, not > a ResultEvent. When we make AMF calls this is handled perfectly. Server > side throws an exception. Our AMF fault handler interrogates the > FaultEvent > and sees that it is a session time out and handles it. But, when we make > the HTTPService call the server still does what it is suppose to and throws > an exception and that still causes a FaultEvent, but in our fault handler > for the HTTPService call I do not see anywhere in the FaultEvent anything > that tells me what the issue was. > > Our code for handling the AMF faults is: > > // Some non important to this issue code > > var errorMessage : ErrorMessage = ErrorMessage(faultEvent.message); > var rootCause : Object = errorMessage.rootCause; > if ( rootCause != null ) > { > // We have our own well known exception with properties that > tell us what went wrong. > var errorType : String = ( rootCause.hasOwnProperty("type") > ? String(rootCause.type) : null ); > if ( errorType == "INVALID_OR_EXPIRED_CREDENTIALS" ) > { > // Code to publish a session time out to the > application > } > > // Other non important to this issue code > } > > The problem is that even though we throw the same exception, when it is a > HTTPService call this information is not in the FaultEvent. I see no > information from our backend processing at all anywhere in the FaultEvent. > > Thanks, > Dale > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Cameron > Childress > Sent: Friday, August 21, 2009 12:11 PM > To: [email protected] > Subject: Re: [AFFUG Discuss] Session timeout > > The session timeout occurs because the client hasn't connected in a > long time. This occurs on the server, while not connected to the > client. So.... I may be wrong but I don't think you are ever going > to get a client side Flex Event since this all occurs because the > client hasn't been around in awhile. > > You can always catch it on the server and then have the Client check > for a flag when it reconnects to see when the server session timed > out. > > Someone please correct me if I am wrong. > > -Cameron > > On Fri, Aug 21, 2009 at 10:40 AM, Dale Bronk<[email protected]> wrote: > > Anyone have a good pattern for detecting a session timeout for an > > HTTPService call? We use Java on the backend and while we through a good > > exception on the backend, it doesn’t seem to make in the FaultEvent. > I’ve > > looked everywhere in the FaultEvent and just can’t find any mention of > the > > true exception that was thrown. We have one small portion of the app > that > > is HTTPService calls and the rest is AMF using GraniteDS. We can handle > the > > AMF calls no problem as we can access the Java Exception that was thrown > but > > I’m stumped for the HTTPService calls. > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in > the > subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in > the subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > > > ------------------------------------------------------------- > > To unsubscribe from this list, simply email the list with unsubscribe in > the subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > > List hosted by FusionLink <http://www.fusionlink.com/> > ------------------------------------------------------------- > > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in > the subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by FusionLink <http://www.fusionlink.com> > ------------------------------------------------------------- >
