Any one know what this exception means?

[David Goodenough]

I am using a slightly modified version of HTTPRequest (so that I can set the
ContentType to text/xml as the pre-existing host application I am talking to
requires). That is the only functional change, but obviously I had to make
a view changes to invoke the right HTTPRequestImpl (and I had to have my own
copies). When this comes to call back to the response handler I get:-

Error: [Exception... "'java.lang.ClassCastException' when calling method:
[nsIOnReadyStateChangeHandler::handleEvent]" nsresult: "0x8057001c
(NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "<unknown>" data: no]

in the Javascript console (of Firefox).

The modified code reads:-

private native boolean asyncPostImpl(String user, String pwd, String url,
String postData, ResponseTextHandler handler) /*-{
var xmlHttp =
this.@uk.co.dga.epod.client.XmlHTTPRequestImpl::doCreateXmlHTTPRequest()();
try {
xmlHttp.open("POST", url, true);
xmlHttp.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
xmlHttp.onreadystatechange = function() {
if (xmlHttp.readyState == 4) {
delete xmlHttp.onreadystatechange;
var localHandler = handler;
var responseText = xmlHttp.responseText;
handler = null;
xmlHttp = null;

localHandler.@com.google.gwt.user.client.ResponseTextHandler::onCompletion(Ljava/lang/String;)
(responseText);
}
};
xmlHttp.send(postData);
return true;
}
catch (e) {
delete xmlHttp.onreadystatechange;
handler = null;
xmlHttp = null;
return false;
}
}-*/;

and I guess that the localHandler.@com.google.gwt... line is one causing the
problem. I know it gets into the readyState == 4 block, and I know it does
not get into my handler onCompletion method (which does exist, which does have
a void return and a single String arguement. I have not modified the
ResponseTextHandler code, nor taken a private copy (there was no need).

I am using GWT 1.1.0 on a Linux box, with the app served by Tomcat and Firefox
as the browser.

Any help greatfully received.

David

[David Goodenough]

Turns out I get exactly the same if I stop using my modified HTTPRequest and
use the standard one. So I guess this is nothing to do with my modification.

Anyone met this before?

David

[Scott Blum]

Hi David,

Never seen anything like this!  Is it happening in hosted mode or web mode?  What browser version are you using.

Scott

On 8/17/06, David Goodenough <david.go...@btconnect.com> wrote:

Turns out I get exactly the same if I stop using my modified HTTPRequest and
use the standard one.  So I guess this is nothing to do with my modification.

Anyone met this before?

David

On Wednesday 16 August 2006 22:58, David Goodenough wrote:
> I am using a slightly modified version of HTTPRequest (so that I can set
> the ContentType to text/xml as the pre-existing host application I am
> talking to requires).  That is the only functional change, but obviously I
> had to make a view changes to invoke the right HTTPRequestImpl (and I had
> to have my own copies).  When this comes to call back to the response
> handler I get:-
>
> Error: [Exception... "' java.lang.ClassCastException' when calling method:
> [nsIOnReadyStateChangeHandler::handleEvent]"  nsresult: "0x8057001c
> (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "<unknown>"  data: no]
>
> in the Javascript console (of Firefox).
>
> The modified code reads:-
>
>   private native boolean asyncPostImpl(String user, String pwd, String url,
> String postData, ResponseTextHandler handler) /*-{
>     var xmlHttp =
> this.@uk.co.dga.epod.client.XmlHTTPRequestImpl::doCreateXmlHTTPRequest()();
>     try {
>       xmlHttp.open("POST", url, true);

>       xmlHttp.setRequestHeader ("Content-Type", "text/xml; charset=utf-8");

[David Goodenough]

Scott,

As it says at the bottom, this was Firefox (1.5.0.4) served from Linux. It
turned out that this was not a problem where I thought it was at all, but
was a problem in the way I was using the XML code (the removeWhiteSpace
problem I think).

BTW, running Firefox (which I have to as Konqueror is not yet supported) I
notice that it reports lots of Javascript warnings. Some look benign, but
is there a bug tracking their resolution and making sure they are benign?

Talking of Konqueror why is it not supported? Under the skin both Safari
and Konqueror use the same engine (khtml), and although old Konqueror was
not much use in the Javascript/AJAX world since Safari's fixes were put
back into it, it has been much better (exactly like Safari in fact). Could
it be recognised as an alias for Safari? If you want some help testing
I would be happy to help.

David

> > > xmlHttp.setRequestHeader("Content-Type", "text/xml;

[Scott Blum]

Glad you found the problem, I wouldn't have had a clue where to start
on that. :D

As far as the FF warnings.. I'm pretty sure a basic GWT app can and
should run without warnings if everything is in a good state. I would
see if I can track those down. In hosted mode, exceptions escaping to
the browser should show up as red logged items in the tree log. In web
mode, as you observed, they go to the FF console. For the windows
users, with Visual Studio installed and the right settings in IE, you
can debug from the point of failure.

With regards to Konqueror, I don't think there's any reason we
wouldn't eventually support it, but there are a lot of high priority
items. If you'd like to play around with it, you can modify
UserAgent.gwt.xml to recognize Konqueror's user agent string and
return a new "konqueror" property value. Then you'd need to go into
the other gwt.xml's in gwt-user.jar that depend on UserAgent.gwt.xml
and setup rebind rules for "konqueror". As an initial pass you could
probably just set it to return the Safari implementations and then
fork off from Safari when you run into incompatibilities.

Scott

[David Goodenough]

On Friday 18 August 2006 22:01, Scott Blum wrote:
> Glad you found the problem, I wouldn't have had a clue where to start
> on that. :D
>
> As far as the FF warnings.. I'm pretty sure a basic GWT app can and
> should run without warnings if everything is in a good state. I would
> see if I can track those down. In hosted mode, exceptions escaping to
> the browser should show up as red logged items in the tree log. In web
> mode, as you observed, they go to the FF console. For the windows
> users, with Visual Studio installed and the right settings in IE, you
> can debug from the point of failure.

I am trying to use Firebug, but I have not got it going yet. The warnings
only happen in "strict Javascript" mode as far as I can tell.

>
> With regards to Konqueror, I don't think there's any reason we
> wouldn't eventually support it, but there are a lot of high priority
> items. If you'd like to play around with it, you can modify
> UserAgent.gwt.xml to recognize Konqueror's user agent string and
> return a new "konqueror" property value. Then you'd need to go into
> the other gwt.xml's in gwt-user.jar that depend on UserAgent.gwt.xml
> and setup rebind rules for "konqueror". As an initial pass you could
> probably just set it to return the Safari implementations and then
> fork off from Safari when you run into incompatibilities.

I will give it a go.
>
> Scott
>
>