myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: PPR Response Coding Problem with Glassfish
Date Thu, 03 Jul 2008 18:12:59 GMT
On Thu, Jul 3, 2008 at 7:03 PM, Burghard Britzke
<bubi@charmides.in-berlin.de> wrote:
> first of all, this is NOT the issue I filed with (1139) there are only
> similar symptoms.
yes, it was bad from me to hijack this email thread
> 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 table paging? no
>
> 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)
yes, but faclets sends down xhtml as well.
I noticed that in the XML case, in your demo, document.forms is undefined.
I haven't had much time to check it deeper (yes, the 1139 issue)

-M
>
> 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
>
>



-- 
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