Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 95387 invoked from network); 4 Jul 2008 18:21:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jul 2008 18:21:52 -0000 Received: (qmail 98050 invoked by uid 500); 4 Jul 2008 18:21:51 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 98011 invoked by uid 500); 4 Jul 2008 18:21:50 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 98000 invoked by uid 99); 4 Jul 2008 18:21:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jul 2008 11:21:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.109.42.8] (HELO einhorn.in-berlin.de) (192.109.42.8) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jul 2008 18:20:56 +0000 X-Envelope-From: bubi@charmides.in-berlin.de X-Envelope-To: Received: from [192.168.2.26] (p57BB44F1.dip.t-dialin.net [87.187.68.241]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m64IKuih032269 for ; Fri, 4 Jul 2008 20:20:56 +0200 Message-Id: From: Burghard Britzke To: "MyFaces Discussion" In-Reply-To: <71235db40807041043x5f2c2b37j2e6f53b517e7ba3c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: PPR Response Coding Problem with Glassfish Date: Fri, 4 Jul 2008 20:20:55 +0200 References: <9915A404-9795-43FA-AB65-3B30200B30F9@charmides.in-berlin.de> <71235db40807030203r248cc92ek99d7a321eb7af7ed@mail.gmail.com> <4C0CA437-E4CA-4165-BCED-0CDCC259A8A2@charmides.in-berlin.de> <71235db40807031112u68c565b0g9b5f76ae04743eb4@mail.gmail.com> <7E6A1204-F599-498C-B028-B1956B6F34B0@charmides.in-berlin.de> <71235db40807040022t797d6f26n4de5e6e7c2e0ee6d@mail.gmail.com> <71235db40807040839g1263259chc7e137f2eed349e@mail.gmail.com> <71235db40807040854t60c67e3ep584ffe223b0d43f6@mail.gmail.com> <12860F05-D87A-4D91-8CEE-8BAF1F67B6E7@charmides.in-berlin.de> <71235db40807041043x5f2c2b37j2e6f53b517e7ba3c@mail.gmail.com> X-Mailer: Apple Mail (2.926) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Virus-Checked: Checked by ClamAV on apache.org BUT THIS IS NOT THE ISSUE I FILED! this is a completly different one. =20= only the result for the user is similar to that I filed. should I file =20= an issue for this one, too? I think I will do it. Am 04.07.2008 um 19:43 schrieb Matthias Wessendorf: > On Fri, Jul 4, 2008 at 7:31 PM, Burghard Britzke > 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 =20= >> 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: >>> >>> >>> >> xmlns:f=3D"http://java.sun.com/jsf/core" >>> xmlns:h=3D"http://java.sun.com/jsf/html" >>> xmlns:tr=3D"http://myfaces.apache.org/trinidad"> >>> ]]>>> jsp:text> >>> >>> >>> isn't that already one PI too much ? >>> >>> -M >>> >>> On Fri, Jul 4, 2008 at 5:39 PM, Matthias Wessendorf = >> > >>> wrote: >>>> >>>> On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke >>>> wrote: >>>>> >>>>> I found the following solution in the dev.mailing list: >>>>> >>>>> >>>>> = http://mail-archives.apache.org/mod_mbox/myfaces-dev/200709.mbox/%3c127751= 26.post@talk.nabble.com%3e >>>>> >>>>> when I remove the >>>>> >>>>> ]]>>>>> jsp:text> >>>>> >>>>> at my jsp the PPR response does contain only one XML-PI and no =20 >>>>> 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 -content (in =20= >>>>> this >>>>> case >>>>> the XML-PI) into the response before the PPR engine filters the =20= >>>>> rendered >>>>> page. >>>>> to give it a chance I put the element into the =20 >>>>> . So >>>>> it is >>>>> rendered at the beginning of the document but is filtered out =20 >>>>> 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 >>>>>> wrote: >>>>>>> >>>>>>> I catched the response from the server and it contains a double >>>>>>> xml-header >>>>>>> >>>>>>> >>>>>>> = >>>>>> id=3D"j_id_id6">>>>>>> ... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> this comes from Trinidad directly. >>>>>> >>>>>> the "extra" PI is from your page, I guess. >>>>>> >>>>>>> is there a configuration option to prevent this double header =20= >>>>>>> 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 >>>>>>> wrote: >>>>>>> >>>>>>> first of all, this is NOT the issue I filed with (1139) there =20= >>>>>>> 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 =20= >>>>>>> request >>>>>>> while >>>>>>> >>>>>>> on this issue a browser is not capable of parsing the response =20= >>>>>>> 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 =20 >>>>>>> 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 >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> 's page navigation does not work as expected for my >>>>>>> >>>>>>> configuration. >>>>>>> >>>>>>> A klick on one of the navigation buttons sends a request (or =20 >>>>>>> two) to >>>>>>> the >>>>>>> >>>>>>> server. But the response is routed into an empty case of a =20 >>>>>>> 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 =20 >>>>>>> parameter. I >>>>>>> found >>>>>>> >>>>>>> the >>>>>>> >>>>>>> following: >>>>>>> >>>>>>> >>>>>>> >>>>>>> XML-Verarbeitungsfehler: XML- oder Text-Deklaration nicht am =20 >>>>>>> Beginn >>>>>>> der >>>>>>> >>>>>>> Entit=E4t Adresse: >>>>>>> >>>>>>> http://localhost:8080/test/faces/test.jspx Zeile Nr. 1, Spalte =20= >>>>>>> 40: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------^ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> For the endusers it looks like they ran into TRINIDAD-1139. =20 >>>>>>> The only >>>>>>> >>>>>>> difference is that the page is rendered as html 4.01 (not =20 >>>>>>> xhtml). and >>>>>>> >>>>>>> with a >>>>>>> >>>>>>> server side logging the presence of successfull requests can be >>>>>>> >>>>>>> monitored. >>>>>>> >>>>>>> Is it possible to prevent double elements in the ppr =20 >>>>>>> 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 >> >> > > > > --=20 > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org