search

QeelwaEtech / omnifaces

Automatically exported from code.google.com/p/omnifaces
0 stars 1 forks source link

FullAjaxExceptionHandler incorrect partial response #134

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I have created this issue, because FullAjaxExceptionHandler is not responding 
correctly (maybe a JSF error, I need to check).

When the error page is rendered the browser receive this responde (copy of a 
fragment):

<?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><update id="javax.faces.ViewRoot"><![CDATA[<html 
xmlns="http://www.w3.org/1999/xhtml"><head>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

is ignoring the DOCTYPE, I attached the image again...

Original issue reported on code.google.com by SaW...@gmail.com on 4 Feb 2013 at 7:44

Attachments:

GoogleCodeExporter commented 9 years ago 
This image show the response with firebug... I'm using: PF 3.5 Final, OmniFaces 
1.4-SNAPSHOT-20130202, JSF (Mojarra) 2.1.17

Original comment by SaW...@gmail.com on 4 Feb 2013 at 7:48

Attachments:

GoogleCodeExporter commented 9 years ago 
I can't reproduce it on 
http://showcase.omnifaces.org/exceptionhandlers/FullAjaxExceptionHandler

The doctype in the ajax response is not mandatory. It may be more helpful if 
you show the entire XML response. If necessary, remove sensitive information 
from the error page while still reproducing the problem. Better would be to 
isolate the problem in flavor of a WAR.

Original comment by balusc on 4 Feb 2013 at 8:15

GoogleCodeExporter commented 9 years ago 
To exclude an unresetted response from being the cause, I made a local change 
in the FullAjaxExceptionHandler (which isn't committed) which will always reset 
the response even if currently not in render response.

Give the attached snapshot a try and let me know.

Original comment by balusc on 4 Feb 2013 at 8:21

Attachments:

GoogleCodeExporter commented 9 years ago 
I have tested with JSF (Mojarra) 2.1.6 (old version) and the response is 
different:

<?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><update id="javax.faces.ViewRoot"><![CDATA[<!DOCTYPE 
html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

doctype is included and the page is rendered correctly... maybe is related to 
JSF, Do you know where can be the problem in JSF?

Original comment by SaW...@gmail.com on 4 Feb 2013 at 8:36

GoogleCodeExporter commented 9 years ago 
Interesting. Thank you for this finding, now I've something to investigate. I 
recall a similar problem when doctype is also declared in an include file or 
template client.

I'd like to know one more thing: does this problem also occur when you step 
back to PrimeFaces 3.4.x and OmniFaces 1.3 while keeping  Mojarra 2.1.17?

Original comment by balusc on 4 Feb 2013 at 8:44

GoogleCodeExporter commented 9 years ago 
Related Mojarra issue: http://java.net/jira/browse/JAVASERVERFACES-2575

Original comment by balusc on 4 Feb 2013 at 8:45

GoogleCodeExporter commented 9 years ago 
I can't use Primefaces 3.4.x because I get errors with Mojarra 2.1.17... I 
changed the bundled jar in glassfish to 2.1.6 and again to 2.1.17, now the 
problem dissapeared. Before to make that I deleted the glassfish and Netbeans 
cache to test... I don't understand what happened... :/

Maybe is related to Mojarra 2.1.17, because in this moment I can't change the 
doctype to <!DOCTYPE html>, always is rendered like transitional, using 2.1.6 I 
can change it... You don't need to commit the last change, your code was Ok... 
:)

Original comment by SaW...@gmail.com on 4 Feb 2013 at 8:57

GoogleCodeExporter commented 9 years ago 
Okay. It'll be the cache. Thank you for reporting back.

Original comment by balusc on 4 Feb 2013 at 9:07

GoogleCodeExporter commented 9 years ago 
Balus, I need continue with this if you have time. Check this image, head 
render is duplicated in the body, that's the reason because 
"http://www.w3.org/1999/xhtml" is printed. I need your help to resolve it, if 
is related to JSF anyway this can't be ignored.

Original comment by SaW...@gmail.com on 4 Feb 2013 at 10:52

Attachments:

GoogleCodeExporter commented 9 years ago 
This screenshot is from OmniFaces Showcase, the box in green shows javascript 
rendered twice. Is correct?

Original comment by SaW...@gmail.com on 5 Feb 2013 at 7:04

Attachments:

GoogleCodeExporter commented 9 years ago 
Have you tried the snapshot as provided in 
http://code.google.com/p/omnifaces/issues/detail?id=134#c3 ?

Original comment by balusc on 5 Feb 2013 at 7:06

GoogleCodeExporter commented 9 years ago 
yes... I have updated to Mojarra 2.1.18 but the problem persist... I tested 
deleting the cache in glassfish, netbeans, browsers (Firefox, Chrome, Safari, 
IE).

Original comment by SaW...@gmail.com on 5 Feb 2013 at 8:45

GoogleCodeExporter commented 9 years ago 
This look like a dirty response buffer. Have you set an 
javax.faces.FACELETS_BUFFER_SIZE in web.xml? Try setting it to something high, 
e.g. 100000. Still, a concrete WAR which demonstrates the problem would be very 
helpful.

The duplicate GA entry in showcase is browser-specific quirk (Chrome/FF expose 
this, IE not) during updating the HTML DOM and not related to JSF. It doesn't 
appear as such in the ajax response body.

Original comment by balusc on 5 Feb 2013 at 11:01

GoogleCodeExporter commented 9 years ago 
Problem fixed, is a problem with primefaces, when I add "styleClass" to h:body 
and then click on p:commandButton the resources are being rendered in h:body. 
wow... ridiculous error... :/

Original comment by SaW...@gmail.com on 5 Feb 2013 at 11:03

GoogleCodeExporter commented 9 years ago 
Wow, good find. I indeed reproduced it by just adding styleClass="foo" to the 
<h:body> of the error page and triggering an exception during a PrimeFaces ajax 
request. So, when using standard JSF ajax request or PF non-ajax request, it 
works fine. It occurred with both Mojarra 2.1.17 and MyFaces 2.1.10.

Look like a bug in PF JS/ajax engine, that it failed to properly replace the 
body with the one from the ajax response.

At least, not an OmniFaces issue and I also don't see ways to fix it from 
OmniFaces on. I will at least update the KnownIssues page about this issue. 
Again, thank you for nailing down the particular issue.

Original comment by balusc on 6 Feb 2013 at 12:00

GoogleCodeExporter commented 9 years ago 
I'm using PF 3.5... Thanks for the workaround... :D

Original comment by SaW...@gmail.com on 6 Feb 2013 at 12:50