[seam-dev] Re: [Richfaces-exadel] Concurrent requests (event queue and error condition)
Pete Muir
pmuir at redhat.com
Fri Sep 19 07:47:42 EDT 2008
Hi Ted
Sorry for the late reply - Judy has moved this to https://jira.jboss.org/jira/browse/JBSEAM-3426
On 10 Sep 2008, at 00:03, Ted Goddard wrote:
>
> 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 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
>>>
>>
>
>
More information about the seam-dev
mailing list