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 Fri, 04 Jul 2008 15:39:18 GMT
On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke
<bubi@charmides.in-berlin.de> wrote:
> I found the following solution in the dev.mailing list:
>
> http://mail-archives.apache.org/mod_mbox/myfaces-dev/200709.mbox/%3c12775126.post@talk.nabble.com%3e
>
> when I remove the
>
> <jsp:text><![CDATA[<?xml version="1.0" encoding="UTF-8" ?>]]></jsp:text>
>
> at my jsp the PPR response does contain only one XML-PI and no parse error
> occure.

yes, that workaround I found as well.
But, looks not like a desired step.

>
> It seems that the jsp servlet pushes its <jsp:text>-content (in this case
> the XML-PI) into the response before the PPR engine filters the rendered
> page.
> to give it a chance I put the <jsp:text> element into the <f:view>. So it
is
> rendered at the beginning of the document but is filtered out during PPR.
>
> May be that there is a better way?

not sure yet. Was busy. Not looked into this in detail, at all

-Matthias

>
>
> Am 04.07.2008 um 09:22 schrieb Matthias Wessendorf:
>
>> Hi,
>>
>> On Fri, Jul 4, 2008 at 9:11 AM, Burghard Britzke
>> <bubi@charmides.in-berlin.de> wrote:
>>>
>>> I catched the response from the server and it contains a double
>>> xml-header
>>> <?xml version="1.0" encoding="UTF-8" ?><?xml version="1.0" ?>
>>> <?Tr-XHR-Response-Type ?>
>>> <content action="/test/faces/test.jspx"> <fragment><![CDATA[<div
>>> id="j_id_id6"><table cellpadding="0"...
>>> ...
>>
>> <?xml version="1.0" ?>
>> <?Tr-XHR-Response-Type ?>
>>
>> this comes from Trinidad directly.
>>
>> the "extra" PI is from your page, I guess.
>>
>>> is there a configuration option to prevent this double header in the ppr
>>> response?
>>
>> not that I am aware of.
>> I need to run some tests on our library.
>>
>>>
>>> Am 03.07.2008 um 20:12 schrieb Matthias Wessendorf:
>>>
>>> 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
>>>
>>>
>>
>>
>>
>> --
>> 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