Doug - That actually a good idea.. Still interested in knowning why the error code not going up though...
On Sun, Aug 23, 2009 at 9:21 AM, Douglas Knudsen <[email protected]>wrote: > 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/> >> ------------------------------------------------------------- >> > >
