Re: [Richfaces-exadel] Concurrent requests (event queue and error condition)
by Pete Muir
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
>
17 years, 10 months
Exporting datatables
by Nicklas Karlsson
Hi,
While looking for css parsing for the excel-export of datatables, I
recalled running into https://xhtmlrenderer.dev.java.net/ before. What
it essentially
does is parses xhtml and converts it to pdf/image/svg, taking
stylesheets etc into account.
Does anyone here have any insight on if it would be possible in JSF
to, given a component id, dig it out, render it to a temporary
document, strip
out the other components from the body with exception of the component
to export and its parents (preserving stylesheet info), make sure it's
xhtml compliant
(through TagSoup or some other library), convert it to the target
format (through the xhtmlrenderer) and hanging the result on the
DocumentStore?
It could be handy to make in-application screenshots (targetting the
root) to pdf/image or just to target a component (datatable) to
export(?)
---
Nik
17 years, 10 months
PARAM_BUILD_BEFORE_RESTORE
by Dan Allen
Hey guys,
During the panel discussion last night as JSF One, I learned about an
undocumented feature in Facelets, which may be just the solution you
were looking for, Christian, regarding stale views on a login or other
public form page. Facelets has the ability to build the view during
the restore view phase if on postback the view state couldn't be
found. You simply set the context parameter PARAM_BUILD_BEFORE_RESTORE
to true. As it turns out, this is going to be the default behavior in
JSF 2.0 to avoid the very problem that you observed, that a stale
login page would reject a login, throw up a confusing message, and ask
the user to try again.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
17 years, 10 months
Was Seam TDD?
by Przemysław Szkudlarek
Hello,
Is Seam Framwork developed using Test-Driven Development? Test-Driven Development requires a failing test case before any changes to the production code. So what I mean is: did you write unit test before the production code?
I've posted a similar thread in http://seamframework.org/Community/IsSeamTDD but I didn't get any satisfying answer.
Best regards,
Przemek Szkudlarek
17 years, 10 months
hot deployment broken in trunk
by Dan Allen
I switched over to using Seam trunk to prepare some demos for my talks
and I quickly discovered that hot deployment is not working. The
problem is that the hot deployment routine in Initialization is trying
to access a non-initialized private field, hotDeploymentStrategy. In
Seam 2.0, the strategy was setup both at initial deployment and hot
deployment. In Seam trunk, the setup does not occur during hot
deployment.
I fixed it by changing (around line 664):
//TODO open the ability to reuse the classloader by looking at the
components class classloaders
// Rescan
hotDeploymentStrategy.scan();
// And install
installHotDeployableComponents();
Pages.instance().setHotDotPageDotXmlFileNames(DotPageDotXmlDeploymentHandler.hotInstance().getFiles());
to:
createHotDeployment(Thread.currentThread().getContextClassLoader());
//Pages.instance().setHotDotPageDotXmlFileNames(DotPageDotXmlDeploymentHandler.hotInstance().getFiles());
I had to comment out the scanning for new .page.xml files because
somewhere it was throwing a null pointer that I didn't track down.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
17 years, 10 months
