myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burghard Britzke <b...@charmides.in-berlin.de>
Subject Re: PPR Response Coding Problem with Glassfish
Date Thu, 03 Jul 2008 17:03:46 GMT
first of all, this is NOT the issue I filed with (1139) there are only  
similar symptoms.
but there is a significant difference: (1139) does not send a request  
while on this issue a browser is not capable of parsing the response  
because it has two xml headers.
is there a way to switch of ppr?

for your statement: it does not depend on wether facelets or jsp. it  
is a pure client side problem. it depends on html or xhtml/xml (imo)

Am 03.07.2008 um 11:03 schrieb Matthias Wessendorf:

> I did a quick look at the issue, you filed (1139).
> It is strange that xhtml is causing these kinda problems.
> works fine with facelets.
>
> give me some time to verify the root issues, instead
> of doing a simple "getElementById". I think there are
> more similar issue to your problem.
> -M
>
> On Thu, Jul 3, 2008 at 8:33 AM, Burghard Britzke
> <bubi@charmides.in-berlin.de> wrote:
>> with the following environment:
>> Mac OS X 10.5.4
>> Sun AS 9.0.2 (Glassfish)
>> Java 1.5
>> Safari 3.1.2 and Firefox 3.0
>> <tr:table>'s page navigation does not work as expected for my  
>> configuration.
>> A klick on one of the navigation buttons sends a request (or two)  
>> to the
>> server. But the response  is routed into an empty case of a chained  
>> if
>> statement in the js-function _handlePprResponse() in file
>> DebugCommon1_2_8.js.
>> 20723 else
>> 20723 {
>> 20724 // FIXME: log an error
>> 20725 }
>> 20726}
>> This is because the rootNodeName is "parseerror". I checked the
>> documentElement which is passed to that function as a parameter. I  
>> found the
>> following:
>> <parseerror>
>>   XML-Verarbeitungsfehler: XML- oder Text-Deklaration nicht am  
>> Beginn der
>> Entität Adresse:
>>   http://localhost:8080/test/faces/test.jspx Zeile Nr. 1, Spalte 40:
>>   <sourcetext>
>>     <?xml version="1.0" encoding="UTF-8" ?><?xml version="1.0" ?>
>>     ---------------------------------------^
>>   </sourcetext>
>> </parsererror>
>> For the endusers it looks like they ran into TRINIDAD-1139. The only
>> difference is that the page is rendered as html 4.01 (not xhtml).  
>> and with a
>> server side logging the presence of successfull requests can be  
>> monitored.
>> Is it possible to prevent double <?XML?> elements in the ppr  
>> response by
>> configuration?
>>
>>
>>
>>
>>
>>
>
>
>
> -- 
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org


Mime
View raw message