On Fri, Jul 4, 2008 at 8:20 PM, Burghard Britzke <[EMAIL PROTECTED]> wrote: > BUT THIS IS NOT THE ISSUE I FILED!
hey, what's wrong with your keyboard ? this is a completly different one. only > the result for the user is similar to that I filed. should I file an issue > for this one, too? I think I will do it. well, the source of issue is that currently almost everything has hick-ups, when this is inculded: issues: -client-side issues (the one you filed, 1139) -two PIs on PPR response. I am currently looking into the client-side issue... -M > > > Am 04.07.2008 um 19:43 schrieb Matthias Wessendorf: > >> On Fri, Jul 4, 2008 at 7:31 PM, Burghard Britzke >> <[EMAIL PROTECTED]> wrote: >>> >>> no! >>> for the jsp only the first one is the XML-PI. >>> the second one is only CDATA. >>> but at the rendered page the first does not appear. only the XML-PI which >>> is >>> in the CDATA is rendered. >>> that is the magic of jsp. >> >> ok, well looks like not really supported right now. >> The report you forwarded has a good description; >> Do you add that info to the bug you filed, so that we don't loose it ? >> >> -M >> >>> >>> Am 04.07.2008 um 17:54 schrieb Matthias Wessendorf: >>> >>>> quick question. >>>> >>>> your test,jspx start like this: >>>> >>>> <?xml version="1.0" encoding="UTF-8" ?> >>>> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"; version="2.0" >>>> xmlns:f="http://java.sun.com/jsf/core"; >>>> xmlns:h="http://java.sun.com/jsf/html"; >>>> xmlns:tr="http://myfaces.apache.org/trinidad";> >>>> <jsp:text><![CDATA[<?xml version="1.0" encoding="UTF-8" >>>> ?>]]></jsp:text> >>>> >>>> >>>> isn't that already one PI too much ? >>>> >>>> -M >>>> >>>> On Fri, Jul 4, 2008 at 5:39 PM, Matthias Wessendorf <[EMAIL PROTECTED]> >>>> wrote: >>>>> >>>>> On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke >>>>> <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> I found the following solution in the dev.mailing list: >>>>>> >>>>>> >>>>>> >>>>>> http://mail-archives.apache.org/mod_mbox/myfaces-dev/200709.mbox/[EMAIL >>>>>> PROTECTED] >>>>>> >>>>>> 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 >>>>>>> <[EMAIL PROTECTED]> 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 >>>>>>>> <[EMAIL PROTECTED]> 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 >>>>>>>> >>>>>>>> <[EMAIL PROTECTED]> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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
