Thanks Shane, Sergey, I've mentioned what each framework will do when
an error is received in the docs.
I also filed
so that we
can add HTTP headers when an error is sent, allowing us to send the
RFC recommended Retry-After header which should allow the
implementation of Ted's suggestion of retrying after a period of time.
On 3 Sep 2008, at 04:57, Shane Bryzak wrote:
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(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
>>
>
_______________________________________________
Richfaces-exadel mailing list
Richfaces-exadel(a)redhat.com
https://www.redhat.com/mailman/listinfo/richfaces-exadel