You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by David Brunette <Da...@chordiant.com> on 2007/06/22 16:25:38 UTC
[Trinidad] AJAX PPR - Invalid PPR Response error
Hello...
I took a 1.0.2 build from the trunk a couple of days ago to start
testing our app against the latest and greatest PPR functionality (using
AJAX). After deploying the demo WAR to Tomcat, everything on the PPR
Demo page worked great. But when I took the same demo WAR and deployed
it to Weblogic 9.2, I started getting "Invalid PPR Response" errors
whenever I tried anything on that page.
Digging into the JS with Firebug, I can see that the
_requestStatusChanged() function gets a statusCode of 200, but is
failing because requestEvent.getResponseXML() is null. (Side note:
requestEvent.isPprResponse() is returning 'true' even if
_isResponseValidXML() is 'false'. Not sure if that was intended...).
I've gone about as far as I can go debugging this on my own. I
have no idea what would cause the responseXML to be null... or if I'm
even on the right path. Any help would be much appreciated!
Dave
The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by Adam Winer <aw...@gmail.com>.
On 6/25/07, David Brunette <Da...@chordiant.com> wrote:
>
> Well, our app is using Facelets... so now that I've got a version of the JARs that works with that, I can get back to validating the app that I've got against the latest PPR stuff.
>
> But you're right, this is sounding more like a BEA forum topic now. That's my next stop.
>
> Thanks for the guidance...
Thanks for following up on all this, and please, let us know
on this forum if you find out anything from BEA. If there's
a workaround I can get into the Trinidad code, or at least
one we can document, that'd be great.
-- Adam
RE: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by David Brunette <Da...@chordiant.com>.
Well, our app is using Facelets... so now that I've got a version of the JARs that works with that, I can get back to validating the app that I've got against the latest PPR stuff.
But you're right, this is sounding more like a BEA forum topic now. That's my next stop.
Thanks for the guidance...
Dave
________________________________
From: Adam Winer [mailto:awiner@gmail.com]
Sent: Mon 6/25/2007 7:26 PM
To: MyFaces Development
Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
On 6/25/07, David Brunette <Da...@chordiant.com> wrote:
Sorry... it seems as though it was a bit premature to say that it
was not working with Facelets. After trying a bunch of different
things, I forgot one very important thing to try... get the latest code!
I was about to ask! :) Yeah, the XMLHttp-PPR was
broken with Facelets. The ResponseWriter construction
in Facelets is really tortuous, took awhile to come up with
a solid solution.
After getting a newly built set of JARs this afternoon and trying it
again with Facelets, the PPR works just fine in both Tomcat and
Weblogic. Woops.
But we're still stuck on having the wrong response contentType with
JSP & Weblogic.
Well, that's a better defined problem at least! One possibility -
instead of using the directive, maybe use a JSP scriptlet along
the lines of:
FacesContext fc = FacesContext.getCurrentInstance();
RequestContext rc = RequestContext.getCurrentInstance();
if (!rc.isPartialRequest(fc))
pageContext.getResponse().setContentType("text/html; charset=iso-8859-1")
... though, of course, you'd want to wrap this workaround
up in a tag.
I'm mostly just guessing here, though. You could bring
the general issue to a BEA forum: why do WebLogic 8.1
JSPs set the content type out directly, instead of
going through the ServletResponse API - blowing off
any wrappers added by filters?
-- Adam
The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by Adam Winer <aw...@gmail.com>.
On 6/25/07, David Brunette <Da...@chordiant.com> wrote:
>
>
> Sorry... it seems as though it was a bit premature to say that it
> was not working with Facelets. After trying a bunch of different
> things, I forgot one very important thing to try... get the latest code!
I was about to ask! :) Yeah, the XMLHttp-PPR was
broken with Facelets. The ResponseWriter construction
in Facelets is really tortuous, took awhile to come up with
a solid solution.
After getting a newly built set of JARs this afternoon and trying it
> again with Facelets, the PPR works just fine in both Tomcat and
> Weblogic. Woops.
>
> But we're still stuck on having the wrong response contentType with
> JSP & Weblogic.
Well, that's a better defined problem at least! One possibility -
instead of using the directive, maybe use a JSP scriptlet along
the lines of:
FacesContext fc = FacesContext.getCurrentInstance();
RequestContext rc = RequestContext.getCurrentInstance();
if (!rc.isPartialRequest(fc))
pageContext.getResponse().setContentType("text/html; charset=utf-8")
... though, of course, you'd want to wrap this workaround
up in a tag.
I'm mostly just guessing here, though. You could bring
the general issue to a BEA forum: why do WebLogic 8.1
JSPs set the content type out directly, instead of
going through the ServletResponse API - blowing off
any wrappers added by filters?
-- Adam
RE: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by David Brunette <Da...@chordiant.com>.
Sorry... it seems as though it was a bit premature to say that it
was not working with Facelets. After trying a bunch of different
things, I forgot one very important thing to try... get the latest code!
After getting a newly built set of JARs this afternoon and trying it
again with Facelets, the PPR works just fine in both Tomcat and
Weblogic. Woops.
But we're still stuck on having the wrong response contentType with
JSP & Weblogic.
-----Original Message-----
From: David Brunette [mailto:David.Brunette@chordiant.com]
Sent: Monday, June 25, 2007 3:04 PM
To: MyFaces Development
Subject: RE: [Trinidad] AJAX PPR - Invalid PPR Response error
... Since we're questioning the JSP contentType directive here, I
whipped up a quick test page using Facelets. In this test, the response
contentType IS "text/xml"... but I'm getting a 'parseerror' from the
responseXML. From what I can tell, it looks like the responseText is
returning the entire page DOM, and the " <!DOCTYPE HTML..." part of the
responseText seems to be causing the XML parsing to fail.
So in an attempt to narrow down the original problem, it looks like
I may have just found one more:
1 [original]) With JSP & Weblogic, the contentType specified in
the page is passed along to the PPR response, which causes the
responseXML to be null.
2 [new]) With Facelets (and either Tomcat or Weblogic), the entire
page DOM is returned in the responseText, causing a parseerror and
eventually an "Invalid PPR Response" error.
Hopefully this is helpful and not just a flood of info. One thing
at a time, I suppose...
Dave
-----Original Message-----
From: David Brunette [mailto:David.Brunette@chordiant.com]
Sent: Monday, June 25, 2007 1:44 PM
To: MyFaces Development
Subject: RE: [Trinidad] AJAX PPR - Invalid PPR Response error
Ahhh... I swear that I tried that last week and saw no change, but
I just realized that the page I was changing wasn't actually the one
being used (blurry-eyed developer error!).
OK, seems like you're on the right track with trying to remove that
contentType directive... but simply removing it causes the page to not
load in Weblogic (and while the page will load in Tomcat, it doesn't
work after that). It DOES look like Weblogic is using the contentType
from that directive instead of XmlHttpServletResponse's "text/xml"
because if I change it in the page, then that is the contentType that is
eventually in the response header (I didn't get it to work, just saw
that the contentType was passed through from the JSPX to the response
header).
Still haven't quite formulated an answer here, but it looks like
we're getting somewhere...
-----Original Message-----
From: Adam Winer [mailto:awiner@gmail.com]
Sent: Monday, June 25, 2007 1:20 PM
To: MyFaces Development
Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
On 6/25/07, David Brunette <Da...@chordiant.com> wrote:
>
> OK... so everything in the responseText looks fine... but the
> contentType in the header shows "text/html" instead of "text/xml". I
> can see that XmlHttpServletResponse specifically sets "text/xml", but
> I'm guessing that something further along on the filter chain or
> something is changing it to "text/html".
Ah, that definitely looks like the issue. So the question is "who is
setting the content type to text/html"? It might be the JSP - what
happens if you delete the JSP contentType directive?
> Am I correct in my understanding that we need "text/xml" here...
> and if the contentType is incorrect, then we would get a null
> responseXML, even if the responseText was valid XML?
Yes.
Thanks for investigating this!
-- Adam
> -----Original Message-----
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Friday, June 22, 2007 1:46 PM
> To: MyFaces Development
> Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
>
> There's gotta be some other difference, as what you've
> identified wouldn't result in an invalid XML document.
>
> -- Adam
>
>
> On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> >
> > Thanks Adam.
> >
> > I had a look at that method and the value of
xmlhttp.responseText
> > between Tomcat & Weblogic looked pretty close. The only differences
> > were in the content node of the response text: 1) different tokens
for
> > the STATE (which is, of course, expected), and 2) the Tomcat
response
> > text had an additional fragment that had " <span id=\"rbTarget\"
> > class=\"x0\">selectBoolean set, item 1</span>". The beginning of
each
> > response text was exactly the same:
> >
> > <?xml version=\"1.0\" ?>
> > <?Tr-XHR-Response-Type ?>
> >
> > So I'm guessing that the missing bit of the Weblogic
responseText
> > is the thing to track down... though I don't know whether it is a
> cause
> > or result the error. I'll keep digging, but any other thoughts are
> > welcomed...
> >
> > Dave
> >
> > -----Original Message-----
> > From: Adam Winer [mailto:awiner@gmail.com]
> > Sent: Friday, June 22, 2007 11:28 AM
> > To: MyFaces Development
> > Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
> >
> > David,
> >
> > responseXML is null means the XML document is invalid.
> > Check getResponseText(). There'll likely be something in
> > the response that is getting inserted into the stream, and
> > then the really fun thing is going to be finding out why
> > Weblogic does it. Look especially at the beginning of
> > the document.
> >
> > isPprResponse() just means that "it has the right headers
> > from the server", that is, "It's supposed to be a PPR response".
> >
> > -- Adam
> >
> >
> >
> > On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hello...
> > >
> > >
> > >
> > > I took a 1.0.2 build from the trunk a couple of days ago to
> start
> > > testing our app against the latest and greatest PPR functionality
> > (using
> > > AJAX). After deploying the demo WAR to Tomcat, everything on the
> PPR
> > Demo
> > > page worked great. But when I took the same demo WAR and deployed
> it
> > to
> > > Weblogic 9.2, I started getting "Invalid PPR Response" errors
> whenever
> > I
> > > tried anything on that page.
> > >
> > >
> > >
> > > Digging into the JS with Firebug, I can see that the
> > > _requestStatusChanged() function gets a statusCode of 200, but is
> > failing
> > > because requestEvent.getResponseXML() is null. (Side note:
> > > requestEvent.isPprResponse() is returning 'true' even if
> > > _isResponseValidXML() is 'false'. Not sure if that was
> intended...).
> > >
> > >
> > >
> > > I've gone about as far as I can go debugging this on my own.
I
> > have no
> > > idea what would cause the responseXML to be null... or if I'm even
> on
> > the
> > > right path. Any help would be much appreciated!
> > >
> > >
> > >
> > > Dave
> > > The information transmitted herewith is sensitive information of
> > Chordiant
> > > Software or its customers and is intended only for use to the
> > individual or
> > > entity to which it is addressed. If the reader of this message is
> not
> > the
> > > intended recipient, you are hereby notified that any review,
> > retransmission,
> > > dissemination, distribution, copying or other use of, or taking of
> any
> > > action in reliance upon, this information is strictly prohibited.
If
> > you
> > > have received this communication in error, please contact the
sender
> > and
> > > delete the material from your computer.
> > The information transmitted herewith is sensitive information
of
> Chordiant Software or its customers and is intended only for use to
the
> individual or entity to which it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that
any
> review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon, this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> >
> The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
>
The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
RE: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by David Brunette <Da...@chordiant.com>.
... Since we're questioning the JSP contentType directive here, I
whipped up a quick test page using Facelets. In this test, the response
contentType IS "text/xml"... but I'm getting a 'parseerror' from the
responseXML. From what I can tell, it looks like the responseText is
returning the entire page DOM, and the " <!DOCTYPE HTML..." part of the
responseText seems to be causing the XML parsing to fail.
So in an attempt to narrow down the original problem, it looks like
I may have just found one more:
1 [original]) With JSP & Weblogic, the contentType specified in
the page is passed along to the PPR response, which causes the
responseXML to be null.
2 [new]) With Facelets (and either Tomcat or Weblogic), the entire
page DOM is returned in the responseText, causing a parseerror and
eventually an "Invalid PPR Response" error.
Hopefully this is helpful and not just a flood of info. One thing
at a time, I suppose...
Dave
-----Original Message-----
From: David Brunette [mailto:David.Brunette@chordiant.com]
Sent: Monday, June 25, 2007 1:44 PM
To: MyFaces Development
Subject: RE: [Trinidad] AJAX PPR - Invalid PPR Response error
Ahhh... I swear that I tried that last week and saw no change, but
I just realized that the page I was changing wasn't actually the one
being used (blurry-eyed developer error!).
OK, seems like you're on the right track with trying to remove that
contentType directive... but simply removing it causes the page to not
load in Weblogic (and while the page will load in Tomcat, it doesn't
work after that). It DOES look like Weblogic is using the contentType
from that directive instead of XmlHttpServletResponse's "text/xml"
because if I change it in the page, then that is the contentType that is
eventually in the response header (I didn't get it to work, just saw
that the contentType was passed through from the JSPX to the response
header).
Still haven't quite formulated an answer here, but it looks like
we're getting somewhere...
-----Original Message-----
From: Adam Winer [mailto:awiner@gmail.com]
Sent: Monday, June 25, 2007 1:20 PM
To: MyFaces Development
Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
On 6/25/07, David Brunette <Da...@chordiant.com> wrote:
>
> OK... so everything in the responseText looks fine... but the
> contentType in the header shows "text/html" instead of "text/xml". I
> can see that XmlHttpServletResponse specifically sets "text/xml", but
> I'm guessing that something further along on the filter chain or
> something is changing it to "text/html".
Ah, that definitely looks like the issue. So the question is "who is
setting the content type to text/html"? It might be the JSP - what
happens if you delete the JSP contentType directive?
> Am I correct in my understanding that we need "text/xml" here...
> and if the contentType is incorrect, then we would get a null
> responseXML, even if the responseText was valid XML?
Yes.
Thanks for investigating this!
-- Adam
> -----Original Message-----
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Friday, June 22, 2007 1:46 PM
> To: MyFaces Development
> Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
>
> There's gotta be some other difference, as what you've
> identified wouldn't result in an invalid XML document.
>
> -- Adam
>
>
> On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> >
> > Thanks Adam.
> >
> > I had a look at that method and the value of
xmlhttp.responseText
> > between Tomcat & Weblogic looked pretty close. The only differences
> > were in the content node of the response text: 1) different tokens
for
> > the STATE (which is, of course, expected), and 2) the Tomcat
response
> > text had an additional fragment that had " <span id=\"rbTarget\"
> > class=\"x0\">selectBoolean set, item 1</span>". The beginning of
each
> > response text was exactly the same:
> >
> > <?xml version=\"1.0\" ?>
> > <?Tr-XHR-Response-Type ?>
> >
> > So I'm guessing that the missing bit of the Weblogic
responseText
> > is the thing to track down... though I don't know whether it is a
> cause
> > or result the error. I'll keep digging, but any other thoughts are
> > welcomed...
> >
> > Dave
> >
> > -----Original Message-----
> > From: Adam Winer [mailto:awiner@gmail.com]
> > Sent: Friday, June 22, 2007 11:28 AM
> > To: MyFaces Development
> > Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
> >
> > David,
> >
> > responseXML is null means the XML document is invalid.
> > Check getResponseText(). There'll likely be something in
> > the response that is getting inserted into the stream, and
> > then the really fun thing is going to be finding out why
> > Weblogic does it. Look especially at the beginning of
> > the document.
> >
> > isPprResponse() just means that "it has the right headers
> > from the server", that is, "It's supposed to be a PPR response".
> >
> > -- Adam
> >
> >
> >
> > On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hello...
> > >
> > >
> > >
> > > I took a 1.0.2 build from the trunk a couple of days ago to
> start
> > > testing our app against the latest and greatest PPR functionality
> > (using
> > > AJAX). After deploying the demo WAR to Tomcat, everything on the
> PPR
> > Demo
> > > page worked great. But when I took the same demo WAR and deployed
> it
> > to
> > > Weblogic 9.2, I started getting "Invalid PPR Response" errors
> whenever
> > I
> > > tried anything on that page.
> > >
> > >
> > >
> > > Digging into the JS with Firebug, I can see that the
> > > _requestStatusChanged() function gets a statusCode of 200, but is
> > failing
> > > because requestEvent.getResponseXML() is null. (Side note:
> > > requestEvent.isPprResponse() is returning 'true' even if
> > > _isResponseValidXML() is 'false'. Not sure if that was
> intended...).
> > >
> > >
> > >
> > > I've gone about as far as I can go debugging this on my own.
I
> > have no
> > > idea what would cause the responseXML to be null... or if I'm even
> on
> > the
> > > right path. Any help would be much appreciated!
> > >
> > >
> > >
> > > Dave
> > > The information transmitted herewith is sensitive information of
> > Chordiant
> > > Software or its customers and is intended only for use to the
> > individual or
> > > entity to which it is addressed. If the reader of this message is
> not
> > the
> > > intended recipient, you are hereby notified that any review,
> > retransmission,
> > > dissemination, distribution, copying or other use of, or taking of
> any
> > > action in reliance upon, this information is strictly prohibited.
If
> > you
> > > have received this communication in error, please contact the
sender
> > and
> > > delete the material from your computer.
> > The information transmitted herewith is sensitive information
of
> Chordiant Software or its customers and is intended only for use to
the
> individual or entity to which it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that
any
> review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon, this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> >
> The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
>
The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
RE: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by David Brunette <Da...@chordiant.com>.
Ahhh... I swear that I tried that last week and saw no change, but
I just realized that the page I was changing wasn't actually the one
being used (blurry-eyed developer error!).
OK, seems like you're on the right track with trying to remove that
contentType directive... but simply removing it causes the page to not
load in Weblogic (and while the page will load in Tomcat, it doesn't
work after that). It DOES look like Weblogic is using the contentType
from that directive instead of XmlHttpServletResponse's "text/xml"
because if I change it in the page, then that is the contentType that is
eventually in the response header (I didn't get it to work, just saw
that the contentType was passed through from the JSPX to the response
header).
Still haven't quite formulated an answer here, but it looks like
we're getting somewhere...
-----Original Message-----
From: Adam Winer [mailto:awiner@gmail.com]
Sent: Monday, June 25, 2007 1:20 PM
To: MyFaces Development
Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
On 6/25/07, David Brunette <Da...@chordiant.com> wrote:
>
> OK... so everything in the responseText looks fine... but the
> contentType in the header shows "text/html" instead of "text/xml". I
> can see that XmlHttpServletResponse specifically sets "text/xml", but
> I'm guessing that something further along on the filter chain or
> something is changing it to "text/html".
Ah, that definitely looks like the issue. So the question is "who is
setting the content type to text/html"? It might be the JSP - what
happens if you delete the JSP contentType directive?
> Am I correct in my understanding that we need "text/xml" here...
> and if the contentType is incorrect, then we would get a null
> responseXML, even if the responseText was valid XML?
Yes.
Thanks for investigating this!
-- Adam
> -----Original Message-----
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Friday, June 22, 2007 1:46 PM
> To: MyFaces Development
> Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
>
> There's gotta be some other difference, as what you've
> identified wouldn't result in an invalid XML document.
>
> -- Adam
>
>
> On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> >
> > Thanks Adam.
> >
> > I had a look at that method and the value of
xmlhttp.responseText
> > between Tomcat & Weblogic looked pretty close. The only differences
> > were in the content node of the response text: 1) different tokens
for
> > the STATE (which is, of course, expected), and 2) the Tomcat
response
> > text had an additional fragment that had " <span id=\"rbTarget\"
> > class=\"x0\">selectBoolean set, item 1</span>". The beginning of
each
> > response text was exactly the same:
> >
> > <?xml version=\"1.0\" ?>
> > <?Tr-XHR-Response-Type ?>
> >
> > So I'm guessing that the missing bit of the Weblogic
responseText
> > is the thing to track down... though I don't know whether it is a
> cause
> > or result the error. I'll keep digging, but any other thoughts are
> > welcomed...
> >
> > Dave
> >
> > -----Original Message-----
> > From: Adam Winer [mailto:awiner@gmail.com]
> > Sent: Friday, June 22, 2007 11:28 AM
> > To: MyFaces Development
> > Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
> >
> > David,
> >
> > responseXML is null means the XML document is invalid.
> > Check getResponseText(). There'll likely be something in
> > the response that is getting inserted into the stream, and
> > then the really fun thing is going to be finding out why
> > Weblogic does it. Look especially at the beginning of
> > the document.
> >
> > isPprResponse() just means that "it has the right headers
> > from the server", that is, "It's supposed to be a PPR response".
> >
> > -- Adam
> >
> >
> >
> > On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hello...
> > >
> > >
> > >
> > > I took a 1.0.2 build from the trunk a couple of days ago to
> start
> > > testing our app against the latest and greatest PPR functionality
> > (using
> > > AJAX). After deploying the demo WAR to Tomcat, everything on the
> PPR
> > Demo
> > > page worked great. But when I took the same demo WAR and deployed
> it
> > to
> > > Weblogic 9.2, I started getting "Invalid PPR Response" errors
> whenever
> > I
> > > tried anything on that page.
> > >
> > >
> > >
> > > Digging into the JS with Firebug, I can see that the
> > > _requestStatusChanged() function gets a statusCode of 200, but is
> > failing
> > > because requestEvent.getResponseXML() is null. (Side note:
> > > requestEvent.isPprResponse() is returning 'true' even if
> > > _isResponseValidXML() is 'false'. Not sure if that was
> intended...).
> > >
> > >
> > >
> > > I've gone about as far as I can go debugging this on my own.
I
> > have no
> > > idea what would cause the responseXML to be null... or if I'm even
> on
> > the
> > > right path. Any help would be much appreciated!
> > >
> > >
> > >
> > > Dave
> > > The information transmitted herewith is sensitive information of
> > Chordiant
> > > Software or its customers and is intended only for use to the
> > individual or
> > > entity to which it is addressed. If the reader of this message is
> not
> > the
> > > intended recipient, you are hereby notified that any review,
> > retransmission,
> > > dissemination, distribution, copying or other use of, or taking of
> any
> > > action in reliance upon, this information is strictly prohibited.
If
> > you
> > > have received this communication in error, please contact the
sender
> > and
> > > delete the material from your computer.
> > The information transmitted herewith is sensitive information
of
> Chordiant Software or its customers and is intended only for use to
the
> individual or entity to which it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that
any
> review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon, this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> >
> The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
>
The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by Adam Winer <aw...@gmail.com>.
On 6/25/07, David Brunette <Da...@chordiant.com> wrote:
>
> OK... so everything in the responseText looks fine... but the
> contentType in the header shows "text/html" instead of "text/xml". I
> can see that XmlHttpServletResponse specifically sets "text/xml", but
> I'm guessing that something further along on the filter chain or
> something is changing it to "text/html".
Ah, that definitely looks like the issue. So the question is "who is
setting the content type to text/html"? It might be the JSP - what
happens if you delete the JSP contentType directive?
> Am I correct in my understanding that we need "text/xml" here...
> and if the contentType is incorrect, then we would get a null
> responseXML, even if the responseText was valid XML?
Yes.
Thanks for investigating this!
-- Adam
> -----Original Message-----
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Friday, June 22, 2007 1:46 PM
> To: MyFaces Development
> Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
>
> There's gotta be some other difference, as what you've
> identified wouldn't result in an invalid XML document.
>
> -- Adam
>
>
> On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> >
> > Thanks Adam.
> >
> > I had a look at that method and the value of xmlhttp.responseText
> > between Tomcat & Weblogic looked pretty close. The only differences
> > were in the content node of the response text: 1) different tokens for
> > the STATE (which is, of course, expected), and 2) the Tomcat response
> > text had an additional fragment that had " <span id=\"rbTarget\"
> > class=\"x0\">selectBoolean set, item 1</span>". The beginning of each
> > response text was exactly the same:
> >
> > <?xml version=\"1.0\" ?>
> > <?Tr-XHR-Response-Type ?>
> >
> > So I'm guessing that the missing bit of the Weblogic responseText
> > is the thing to track down... though I don't know whether it is a
> cause
> > or result the error. I'll keep digging, but any other thoughts are
> > welcomed...
> >
> > Dave
> >
> > -----Original Message-----
> > From: Adam Winer [mailto:awiner@gmail.com]
> > Sent: Friday, June 22, 2007 11:28 AM
> > To: MyFaces Development
> > Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
> >
> > David,
> >
> > responseXML is null means the XML document is invalid.
> > Check getResponseText(). There'll likely be something in
> > the response that is getting inserted into the stream, and
> > then the really fun thing is going to be finding out why
> > Weblogic does it. Look especially at the beginning of
> > the document.
> >
> > isPprResponse() just means that "it has the right headers
> > from the server", that is, "It's supposed to be a PPR response".
> >
> > -- Adam
> >
> >
> >
> > On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hello...
> > >
> > >
> > >
> > > I took a 1.0.2 build from the trunk a couple of days ago to
> start
> > > testing our app against the latest and greatest PPR functionality
> > (using
> > > AJAX). After deploying the demo WAR to Tomcat, everything on the
> PPR
> > Demo
> > > page worked great. But when I took the same demo WAR and deployed
> it
> > to
> > > Weblogic 9.2, I started getting "Invalid PPR Response" errors
> whenever
> > I
> > > tried anything on that page.
> > >
> > >
> > >
> > > Digging into the JS with Firebug, I can see that the
> > > _requestStatusChanged() function gets a statusCode of 200, but is
> > failing
> > > because requestEvent.getResponseXML() is null. (Side note:
> > > requestEvent.isPprResponse() is returning 'true' even if
> > > _isResponseValidXML() is 'false'. Not sure if that was
> intended...).
> > >
> > >
> > >
> > > I've gone about as far as I can go debugging this on my own. I
> > have no
> > > idea what would cause the responseXML to be null... or if I'm even
> on
> > the
> > > right path. Any help would be much appreciated!
> > >
> > >
> > >
> > > Dave
> > > The information transmitted herewith is sensitive information of
> > Chordiant
> > > Software or its customers and is intended only for use to the
> > individual or
> > > entity to which it is addressed. If the reader of this message is
> not
> > the
> > > intended recipient, you are hereby notified that any review,
> > retransmission,
> > > dissemination, distribution, copying or other use of, or taking of
> any
> > > action in reliance upon, this information is strictly prohibited. If
> > you
> > > have received this communication in error, please contact the sender
> > and
> > > delete the material from your computer.
> > The information transmitted herewith is sensitive information of
> Chordiant Software or its customers and is intended only for use to the
> individual or entity to which it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that any
> review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon, this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> >
> The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
>
RE: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by David Brunette <Da...@chordiant.com>.
OK... so everything in the responseText looks fine... but the
contentType in the header shows "text/html" instead of "text/xml". I
can see that XmlHttpServletResponse specifically sets "text/xml", but
I'm guessing that something further along on the filter chain or
something is changing it to "text/html".
Am I correct in my understanding that we need "text/xml" here...
and if the contentType is incorrect, then we would get a null
responseXML, even if the responseText was valid XML?
Dave
-----Original Message-----
From: Adam Winer [mailto:awiner@gmail.com]
Sent: Friday, June 22, 2007 1:46 PM
To: MyFaces Development
Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
There's gotta be some other difference, as what you've
identified wouldn't result in an invalid XML document.
-- Adam
On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
>
> Thanks Adam.
>
> I had a look at that method and the value of xmlhttp.responseText
> between Tomcat & Weblogic looked pretty close. The only differences
> were in the content node of the response text: 1) different tokens for
> the STATE (which is, of course, expected), and 2) the Tomcat response
> text had an additional fragment that had " <span id=\"rbTarget\"
> class=\"x0\">selectBoolean set, item 1</span>". The beginning of each
> response text was exactly the same:
>
> <?xml version=\"1.0\" ?>
> <?Tr-XHR-Response-Type ?>
>
> So I'm guessing that the missing bit of the Weblogic responseText
> is the thing to track down... though I don't know whether it is a
cause
> or result the error. I'll keep digging, but any other thoughts are
> welcomed...
>
> Dave
>
> -----Original Message-----
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Friday, June 22, 2007 11:28 AM
> To: MyFaces Development
> Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
>
> David,
>
> responseXML is null means the XML document is invalid.
> Check getResponseText(). There'll likely be something in
> the response that is getting inserted into the stream, and
> then the really fun thing is going to be finding out why
> Weblogic does it. Look especially at the beginning of
> the document.
>
> isPprResponse() just means that "it has the right headers
> from the server", that is, "It's supposed to be a PPR response".
>
> -- Adam
>
>
>
> On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> >
> >
> >
> >
> >
> >
> > Hello...
> >
> >
> >
> > I took a 1.0.2 build from the trunk a couple of days ago to
start
> > testing our app against the latest and greatest PPR functionality
> (using
> > AJAX). After deploying the demo WAR to Tomcat, everything on the
PPR
> Demo
> > page worked great. But when I took the same demo WAR and deployed
it
> to
> > Weblogic 9.2, I started getting "Invalid PPR Response" errors
whenever
> I
> > tried anything on that page.
> >
> >
> >
> > Digging into the JS with Firebug, I can see that the
> > _requestStatusChanged() function gets a statusCode of 200, but is
> failing
> > because requestEvent.getResponseXML() is null. (Side note:
> > requestEvent.isPprResponse() is returning 'true' even if
> > _isResponseValidXML() is 'false'. Not sure if that was
intended...).
> >
> >
> >
> > I've gone about as far as I can go debugging this on my own. I
> have no
> > idea what would cause the responseXML to be null... or if I'm even
on
> the
> > right path. Any help would be much appreciated!
> >
> >
> >
> > Dave
> > The information transmitted herewith is sensitive information of
> Chordiant
> > Software or its customers and is intended only for use to the
> individual or
> > entity to which it is addressed. If the reader of this message is
not
> the
> > intended recipient, you are hereby notified that any review,
> retransmission,
> > dissemination, distribution, copying or other use of, or taking of
any
> > action in reliance upon, this information is strictly prohibited. If
> you
> > have received this communication in error, please contact the sender
> and
> > delete the material from your computer.
> The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
>
The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by Adam Winer <aw...@gmail.com>.
There's gotta be some other difference, as what you've
identified wouldn't result in an invalid XML document.
-- Adam
On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
>
> Thanks Adam.
>
> I had a look at that method and the value of xmlhttp.responseText
> between Tomcat & Weblogic looked pretty close. The only differences
> were in the content node of the response text: 1) different tokens for
> the STATE (which is, of course, expected), and 2) the Tomcat response
> text had an additional fragment that had " <span id=\"rbTarget\"
> class=\"x0\">selectBoolean set, item 1</span>". The beginning of each
> response text was exactly the same:
>
> <?xml version=\"1.0\" ?>
> <?Tr-XHR-Response-Type ?>
>
> So I'm guessing that the missing bit of the Weblogic responseText
> is the thing to track down... though I don't know whether it is a cause
> or result the error. I'll keep digging, but any other thoughts are
> welcomed...
>
> Dave
>
> -----Original Message-----
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Friday, June 22, 2007 11:28 AM
> To: MyFaces Development
> Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
>
> David,
>
> responseXML is null means the XML document is invalid.
> Check getResponseText(). There'll likely be something in
> the response that is getting inserted into the stream, and
> then the really fun thing is going to be finding out why
> Weblogic does it. Look especially at the beginning of
> the document.
>
> isPprResponse() just means that "it has the right headers
> from the server", that is, "It's supposed to be a PPR response".
>
> -- Adam
>
>
>
> On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
> >
> >
> >
> >
> >
> >
> > Hello...
> >
> >
> >
> > I took a 1.0.2 build from the trunk a couple of days ago to start
> > testing our app against the latest and greatest PPR functionality
> (using
> > AJAX). After deploying the demo WAR to Tomcat, everything on the PPR
> Demo
> > page worked great. But when I took the same demo WAR and deployed it
> to
> > Weblogic 9.2, I started getting "Invalid PPR Response" errors whenever
> I
> > tried anything on that page.
> >
> >
> >
> > Digging into the JS with Firebug, I can see that the
> > _requestStatusChanged() function gets a statusCode of 200, but is
> failing
> > because requestEvent.getResponseXML() is null. (Side note:
> > requestEvent.isPprResponse() is returning 'true' even if
> > _isResponseValidXML() is 'false'. Not sure if that was intended...).
> >
> >
> >
> > I've gone about as far as I can go debugging this on my own. I
> have no
> > idea what would cause the responseXML to be null... or if I'm even on
> the
> > right path. Any help would be much appreciated!
> >
> >
> >
> > Dave
> > The information transmitted herewith is sensitive information of
> Chordiant
> > Software or its customers and is intended only for use to the
> individual or
> > entity to which it is addressed. If the reader of this message is not
> the
> > intended recipient, you are hereby notified that any review,
> retransmission,
> > dissemination, distribution, copying or other use of, or taking of any
> > action in reliance upon, this information is strictly prohibited. If
> you
> > have received this communication in error, please contact the sender
> and
> > delete the material from your computer.
> The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
>
RE: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by David Brunette <Da...@chordiant.com>.
Thanks Adam.
I had a look at that method and the value of xmlhttp.responseText
between Tomcat & Weblogic looked pretty close. The only differences
were in the content node of the response text: 1) different tokens for
the STATE (which is, of course, expected), and 2) the Tomcat response
text had an additional fragment that had " <span id=\"rbTarget\"
class=\"x0\">selectBoolean set, item 1</span>". The beginning of each
response text was exactly the same:
<?xml version=\"1.0\" ?>
<?Tr-XHR-Response-Type ?>
So I'm guessing that the missing bit of the Weblogic responseText
is the thing to track down... though I don't know whether it is a cause
or result the error. I'll keep digging, but any other thoughts are
welcomed...
Dave
-----Original Message-----
From: Adam Winer [mailto:awiner@gmail.com]
Sent: Friday, June 22, 2007 11:28 AM
To: MyFaces Development
Subject: Re: [Trinidad] AJAX PPR - Invalid PPR Response error
David,
responseXML is null means the XML document is invalid.
Check getResponseText(). There'll likely be something in
the response that is getting inserted into the stream, and
then the really fun thing is going to be finding out why
Weblogic does it. Look especially at the beginning of
the document.
isPprResponse() just means that "it has the right headers
from the server", that is, "It's supposed to be a PPR response".
-- Adam
On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
>
>
>
>
>
>
> Hello...
>
>
>
> I took a 1.0.2 build from the trunk a couple of days ago to start
> testing our app against the latest and greatest PPR functionality
(using
> AJAX). After deploying the demo WAR to Tomcat, everything on the PPR
Demo
> page worked great. But when I took the same demo WAR and deployed it
to
> Weblogic 9.2, I started getting "Invalid PPR Response" errors whenever
I
> tried anything on that page.
>
>
>
> Digging into the JS with Firebug, I can see that the
> _requestStatusChanged() function gets a statusCode of 200, but is
failing
> because requestEvent.getResponseXML() is null. (Side note:
> requestEvent.isPprResponse() is returning 'true' even if
> _isResponseValidXML() is 'false'. Not sure if that was intended...).
>
>
>
> I've gone about as far as I can go debugging this on my own. I
have no
> idea what would cause the responseXML to be null... or if I'm even on
the
> right path. Any help would be much appreciated!
>
>
>
> Dave
> The information transmitted herewith is sensitive information of
Chordiant
> Software or its customers and is intended only for use to the
individual or
> entity to which it is addressed. If the reader of this message is not
the
> intended recipient, you are hereby notified that any review,
retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon, this information is strictly prohibited. If
you
> have received this communication in error, please contact the sender
and
> delete the material from your computer.
The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [Trinidad] AJAX PPR - Invalid PPR Response error
Posted by Adam Winer <aw...@gmail.com>.
David,
responseXML is null means the XML document is invalid.
Check getResponseText(). There'll likely be something in
the response that is getting inserted into the stream, and
then the really fun thing is going to be finding out why
Weblogic does it. Look especially at the beginning of
the document.
isPprResponse() just means that "it has the right headers
from the server", that is, "It's supposed to be a PPR response".
-- Adam
On 6/22/07, David Brunette <Da...@chordiant.com> wrote:
>
>
>
>
>
>
> Hello…
>
>
>
> I took a 1.0.2 build from the trunk a couple of days ago to start
> testing our app against the latest and greatest PPR functionality (using
> AJAX). After deploying the demo WAR to Tomcat, everything on the PPR Demo
> page worked great. But when I took the same demo WAR and deployed it to
> Weblogic 9.2, I started getting "Invalid PPR Response" errors whenever I
> tried anything on that page.
>
>
>
> Digging into the JS with Firebug, I can see that the
> _requestStatusChanged() function gets a statusCode of 200, but is failing
> because requestEvent.getResponseXML() is null. (Side note:
> requestEvent.isPprResponse() is returning 'true' even if
> _isResponseValidXML() is 'false'. Not sure if that was intended…).
>
>
>
> I've gone about as far as I can go debugging this on my own. I have no
> idea what would cause the responseXML to be null… or if I'm even on the
> right path. Any help would be much appreciated!
>
>
>
> Dave
> The information transmitted herewith is sensitive information of Chordiant
> Software or its customers and is intended only for use to the individual or
> entity to which it is addressed. If the reader of this message is not the
> intended recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon, this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.