[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