On 2 Sep 2008, at 19:49, Pete Muir wrote: > > On 2 Sep 2008, at 19:19, Ted Goddard wrote: > >> >> Hi Pete, >> >> The ICEfaces bridge can handle errors to various Ajax responses; for >> instance, >> in some cases the icon in the connection status component will be >> changed to >> reflect an error response. > > Ok, this is good - means that it should work as it is today with > IceFaces. > > Seam requires a bit of a rejig to make it do this, so I'll work on > that next. So, Seam now throws an exception when it can't serialize a concurrent request, and you can use Seam's standard exception handler to translate that into the appropriate response (e.g. redirect to an error page, send an http error code). I've tested A4Js error handling, and it all works well (e.g. you can pop up a message to the user). Shane, can Seam remoting deal with an HTTP error being sent to it? The changes the user will need to make: 1) Define the exception handling in pages.xml to either send an HTTP error or go to an error page. Sending a 503 error with logging turned off will be the recommended approach. 2a) A4J: alter their templates to override the A4J error handling 2b) ICEfaces: ??? (do nothing by the sound of it) 2c) Seam Remoting: ??? Currently the system boots them out of the conversation, we replace that with throwing an exception, both are equally bad so this shouldn't be too much of regression for existing apps. >> So responding with an error to the Ajax request sounds good ... the >> question is >> how it should be displayed to the user. Or should this error cause >> a retry >> over Ajax after some period of time (and not be displayed to the user >> immediately)? > > I think both these are reasonable options, and should be up to the > developer to choose one. I would say the default behaviour should be > to display a message to the user. It would be great if we could get an example of how to do these for ICEfaces, A4J and Seam remoting into the ref doc. Sergey/Ted/Shane can you provide me with an example of how to customize the behaviour of the framework in both these ways when an HTTP 503 error is sent as the AJAX response? Thanks! > > >> >> >> Regards, >> Ted. >> >> On 2-Sep-08, at 12:06 PM, Pete Muir wrote: >> >>> Ted, Judy, Shane, >>> >>> I've recently been working on >>> https://jira.jboss.org/jira/browse/JBSEAM-1832 and am trying to >>> define better what Seam should do when it cannot successfully >>> serialize requests to the conversation scope (because the queue >>> times out). My preferred solution is to drop the request, and send >>> an error to the browser for it to deal with. I'm looking for your >>> input on the best way to send such an error that will work with >>> different remoting/ajax frameworks. >>> >>> A couple of points >>> >>> 1) Should work ootb - the user should just get some error message >>> in the browser by default, which they can customize >>> 2) Should work the same for all different JS frameworks >>> >>> Having looked at A4J, I notice that it can handle being sent an >>> HTTP error. Semantically, it seems correct to approach it this way >>> (specifically sending a 503) but if we do that, we need a way for >>> (at least) Seam Remoting, A4J and IceFaces to intercept that >>> request and translate it to a message to the user (and not bring up >>> an ugly error message). We can send a detailed error message as >>> the body of the message (e.g. concurrent request) and perhaps add a >>> http header that shows where this error comes from. >>> >>> WDYT? >>> >>> On 2 Sep 2008, at 18:55, Pete Muir wrote: >>> >>>> Seam serializes, also using a timed queue. We need to do >>>> *something* when the event reaches the timeout. Currently, Seam >>>> will make the active conversation inactive, which isn't the best >>>> behaviour, and I think the correct approach is to stay in the >>>> conversation, but to send an error. I took a look at the A4J error >>>> handling, and it looks like the best approach is to send an Http >>>> error to the browser, which can then be intercepted and handled? >>>> Can we provide a default behaviour for this? >>>> >>>> Thanks, >>>> >>>> Pete >>>> >>>> _______________________________________________ >>>> Richfaces-exadel mailing list >>>> Richfaces-exadel(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/richfaces-exadel >>> >> >> >> _______________________________________________ >> Richfaces-exadel mailing list >> Richfaces-exadel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/richfaces-exadel >

It would be great if we could get an example of how to do these for ICEfaces, A4J and Seam remoting into the ref doc. Sergey/Ted/Shane can you provide me with an example of how to customize the behaviour of the framework in both these ways when an HTTP 503 error is sent as the AJAX response?

It would be great if we could get an example of how to do these for ICEfaces, A4J and Seam remoting into the ref doc. Sergey/Ted/Shane can you provide me with an example of how to customize the behaviour of the framework in both these ways when an HTTP 503 error is sent as the AJAX response?

Hi Pete, We've had a chance to look at error conditions further (Jack has been investigating it). The MockViewHandler is invoked from the ExceptionFilter, and it attempts to construct a redirect URL upon error: @Override public String getActionURL(FacesContext ctx, String viewId) { String contextPath = ctx.getExternalContext().getRequestContextPath(); String pathInfo = ctx.getExternalContext().getRequestPathInfo(); String servletPath = ctx.getExternalContext().getRequestServletPath(); if (Strings.isEmpty(pathInfo)) { int loc = viewId.lastIndexOf('.'); if (loc<0) throw new IllegalArgumentException("no file extension in view id: " + viewId); int sploc = servletPath.lastIndexOf('.'); if (sploc<0) throw new IllegalArgumentException("no file extension in servlet path: " + servletPath); return contextPath + viewId.substring(0, loc) + servletPath.substring(sploc); } else { return contextPath + servletPath + viewId; } } The problem is that the URL currently being processed by ICEfaces is an Ajax request, not a page request and the generated URL gets a bit mangled; i.e. we are processing http://localhost:8080/demo/block/send-receive-updates not something like http://localhost:8080/demo/page.seam Here was Jack's analysis: This will result in a redirect URI of /demo/block/error.xhtml. The else-block in the method doesn't take the details of viewId into account. As the desired error page is specified as /error.xhtml the resulting redirect URI should ignore the servletPath as the viewId starts with a slash. (On a side note, if a full URI is specified in the pages.xml, all the elements (contextPath, pathInfo and servletPath should be ignored and the viewId itself should be the redirect URI.) Additionally, the ".xhtml" part of the resulting redirect URI doesn't seem to be replaced by ".seam". If you agree with our analysis so far, Jack can develop a patch for MockViewHandler that handles full page and Ajax requests (we'll go ahead with this unless you recommend otherwise). Cheers, Ted. On 2-Sep-08, at 3:22 PM, Pete Muir wrote: > > On 2 Sep 2008, at 19:49, Pete Muir wrote: > >> >> On 2 Sep 2008, at 19:19, Ted Goddard wrote: >> >>> >>> Hi Pete, >>> >>> The ICEfaces bridge can handle errors to various Ajax responses; >>> for instance, >>> in some cases the icon in the connection status component will be >>> changed to >>> reflect an error response. >> >> Ok, this is good - means that it should work as it is today with >> IceFaces. >> >> Seam requires a bit of a rejig to make it do this, so I'll work on >> that next. > > So, Seam now throws an exception when it can't serialize a > concurrent request, and you can use Seam's standard exception > handler to translate that into the appropriate response (e.g. > redirect to an error page, send an http error code). > > I've tested A4Js error handling, and it all works well (e.g. you > can pop up a message to the user). > > Shane, can Seam remoting deal with an HTTP error being sent to it? > > The changes the user will need to make: > > 1) Define the exception handling in pages.xml to either send an > HTTP error or go to an error page. Sending a 503 error with logging > turned off will be the recommended approach. > 2a) A4J: alter their templates to override the A4J error handling > 2b) ICEfaces: ??? (do nothing by the sound of it) > 2c) Seam Remoting: ??? > > Currently the system boots them out of the conversation, we replace > that with throwing an exception, both are equally bad so this > shouldn't be too much of regression for existing apps. > >>> So responding with an error to the Ajax request sounds good ... >>> the question is >>> how it should be displayed to the user. Or should this error >>> cause a retry >>> over Ajax after some period of time (and not be displayed to the >>> user >>> immediately)? >> >> I think both these are reasonable options, and should be up to the >> developer to choose one. I would say the default behaviour should >> be to display a message to the user. > > It would be great if we could get an example of how to do these for > ICEfaces, A4J and Seam remoting into the ref doc. Sergey/Ted/Shane > can you provide me with an example of how to customize the > behaviour of the framework in both these ways when an HTTP 503 > error is sent as the AJAX response? > > Thanks! > >> >> >>> >>> >>> Regards, >>> Ted. >>> >>> On 2-Sep-08, at 12:06 PM, Pete Muir wrote: >>> >>>> Ted, Judy, Shane, >>>> >>>> I've recently been working on https://jira.jboss.org/jira/browse/JBSEAM-1832 >>>> and am trying to define better what Seam should do when it >>>> cannot successfully serialize requests to the conversation scope >>>> (because the queue times out). My preferred solution is to drop >>>> the request, and send an error to the browser for it to deal >>>> with. I'm looking for your input on the best way to send such an >>>> error that will work with different remoting/ajax frameworks. >>>> >>>> A couple of points >>>> >>>> 1) Should work ootb - the user should just get some error >>>> message in the browser by default, which they can customize >>>> 2) Should work the same for all different JS frameworks >>>> >>>> Having looked at A4J, I notice that it can handle being sent an >>>> HTTP error. Semantically, it seems correct to approach it this >>>> way (specifically sending a 503) but if we do that, we need a >>>> way for (at least) Seam Remoting, A4J and IceFaces to intercept >>>> that request and translate it to a message to the user (and not >>>> bring up an ugly error message). We can send a detailed error >>>> message as the body of the message (e.g. concurrent request) and >>>> perhaps add a http header that shows where this error comes from. >>>> >>>> WDYT? >>>> >>>> On 2 Sep 2008, at 18:55, Pete Muir wrote: >>>> >>>>> Seam serializes, also using a timed queue. We need to do >>>>> *something* when the event reaches the timeout. Currently, Seam >>>>> will make the active conversation inactive, which isn't the >>>>> best behaviour, and I think the correct approach is to stay in >>>>> the conversation, but to send an error. I took a look at the >>>>> A4J error handling, and it looks like the best approach is to >>>>> send an Http error to the browser, which can then be >>>>> intercepted and handled? Can we provide a default behaviour for >>>>> this? >>>>> >>>>> Thanks, >>>>> >>>>> Pete >>>>> >>>>> _______________________________________________ >>>>> Richfaces-exadel mailing list >>>>> Richfaces-exadel(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/richfaces-exadel >>>> >>> >>> >>> _______________________________________________ >>> Richfaces-exadel mailing list >>> Richfaces-exadel(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/richfaces-exadel >> >