[seam-dev] Re: [Richfaces-exadel] Concurrent requests (event queue and error condition)

[Shane Bryzak]

Remoting still doesn't support exception handling very well 
(https://jira.jboss.org/jira/browse/JBSEAM-633) , however the basic 
intention is to handle any HTTP error codes more gracefully than they 
currently are (I think that presently you just get an alert box).  I 
don't think we can reasonably redirect the user to an error page (as 
it's an inline request after all) but we should be able to provide a 
more flexible API to allow developers to define their own behaviour when 
an exception occurs.

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 at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/richfaces-exadel
>>>>
>>>
>>>
>>> _______________________________________________
>>> Richfaces-exadel mailing list
>>> Richfaces-exadel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/richfaces-exadel
>>
>