You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Burghard Britzke <bu...@charmides.in-berlin.de> on 2008/07/03 08:33:32 UTC
PPR Response Coding Problem with Glassfish
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?
Re: PPR Response Coding Problem with Glassfish
Posted by Matthias Wessendorf <ma...@apache.org>.
On Fri, Jul 4, 2008 at 8:20 PM, Burghard Britzke
<bu...@charmides.in-berlin.de> 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
>> <bu...@charmides.in-berlin.de> 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 <ma...@apache.org>
>>>> wrote:
>>>>>
>>>>> On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke
>>>>> <bu...@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
>>>>>>> <bu...@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
>>>>>>>> <bu...@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
>>>>>>>>
>>>>>>>> <bu...@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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
Re: PPR Response Coding Problem with Glassfish
Posted by Burghard Britzke <bu...@charmides.in-berlin.de>.
BUT THIS IS NOT THE ISSUE I FILED! 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.
Am 04.07.2008 um 19:43 schrieb Matthias Wessendorf:
> On Fri, Jul 4, 2008 at 7:31 PM, Burghard Britzke
> <bu...@charmides.in-berlin.de> 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 <matzew@apache.org
>>> >
>>> wrote:
>>>>
>>>> On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke
>>>> <bu...@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
>>>>>> <bu...@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
>>>>>>> <bu...@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
>>>>>>>
>>>>>>> <bu...@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
>>>>
>>>
>>>
>>>
>>> --
>>> 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
Re: PPR Response Coding Problem with Glassfish
Posted by Matthias Wessendorf <ma...@apache.org>.
On Fri, Jul 4, 2008 at 7:31 PM, Burghard Britzke
<bu...@charmides.in-berlin.de> 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 <ma...@apache.org>
>> wrote:
>>>
>>> On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke
>>> <bu...@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
>>>>> <bu...@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
>>>>>> <bu...@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
>>>>>>
>>>>>> <bu...@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
>>>
>>
>>
>>
>> --
>> 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
Re: PPR Response Coding Problem with Glassfish
Posted by Burghard Britzke <bu...@charmides.in-berlin.de>.
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.
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
> <ma...@apache.org> wrote:
>> On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke
>> <bu...@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
>>>> <bu...@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
>>>>> <bu...@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
>>>>>
>>>>> <bu...@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
>>
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
Re: PPR Response Coding Problem with Glassfish
Posted by Matthias Wessendorf <ma...@apache.org>.
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 <ma...@apache.org> wrote:
> On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke
> <bu...@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
>>> <bu...@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
>>>> <bu...@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
>>>>
>>>> <bu...@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
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: PPR Response Coding Problem with Glassfish
Posted by Matthias Wessendorf <ma...@apache.org>.
On Fri, Jul 4, 2008 at 5:31 PM, Burghard Britzke
<bu...@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
>> <bu...@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
>>> <bu...@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
>>>
>>> <bu...@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
Re: PPR Response Coding Problem with Glassfish
Posted by Burghard Britzke <bu...@charmides.in-berlin.de>.
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.
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?
Am 04.07.2008 um 09:22 schrieb Matthias Wessendorf:
> Hi,
>
> On Fri, Jul 4, 2008 at 9:11 AM, Burghard Britzke
> <bu...@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
>> <bu...@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
>>
>> <bu...@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
Re: PPR Response Coding Problem with Glassfish
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
On Fri, Jul 4, 2008 at 9:11 AM, Burghard Britzke
<bu...@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
> <bu...@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
>
> <bu...@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
Re: PPR Response Coding Problem with Glassfish
Posted by Burghard Britzke <bu...@charmides.in-berlin.de>.
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"...
...
is there a configuration option to prevent this double header in the
ppr response?
Am 03.07.2008 um 20:12 schrieb Matthias Wessendorf:
> On Thu, Jul 3, 2008 at 7:03 PM, Burghard Britzke
> <bu...@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
>>> <bu...@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
Re: PPR Response Coding Problem with Glassfish
Posted by Matthias Wessendorf <ma...@apache.org>.
On Thu, Jul 3, 2008 at 7:03 PM, Burghard Britzke
<bu...@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
>> <bu...@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
Re: PPR Response Coding Problem with Glassfish
Posted by Burghard Britzke <bu...@charmides.in-berlin.de>.
first of all, this is NOT the issue I filed with (1139) there are only
similar symptoms.
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 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)
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
> <bu...@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
Re: PPR Response Coding Problem with Glassfish
Posted by Matthias Wessendorf <ma...@apache.org>.
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
<bu...@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