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
