129654 - Need better facilities to debug SOAP calls

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Web Services, defect)

Description

[Michael Percy (obsolete email address)]

We need a better way to find out exactly what is happening in our SOAP calls.
This is definitely something needed for significant SOAP development efforts
using Mozilla as a client platform.

Some suggestions: The SOAP::Lite Perl library allows you to specify a callback
handler when output is sent or recieved. It is called like so:

  my $soap = SOAP::Lite->new();
  $soap->on_debug(\&callback);

And the callback usually looks something like:

  sub callback { print @_; }

It is extremely useful just to be able to do something with the output there.
Another option possibly would be to print to the JavaScript console. Whatever it
is, I would advise against STDOUT, as I don't think that works at all in Win32
windowed apps.

Of course any suggestions on what would be nice ways to debug SOAP calls are
appreciated.

Comment 1

[Michael Percy (obsolete email address)]

Another issue I noticed was that trying to use Venkman to explore the SOAP
objects does not give any useful info, and even crashes Venkman after a while.
Is that just a fact of life related to the C++ implementation of SOAPCall or
would it be possible to create a JS <-> C++ bridge for debugging the guts of the
object? I'd like to take a look at the fields at runtime if possible.

By the way Ray, I hope it's OK I assigned this bug directly to you, let me know
if you want me to do something else. Thanks.

Comment 2

[Ray Whitmer]

We have already made the following efforts:

1.  With a debug compilation, you can see the messages sent and reeceived on the
system output of the browser process.
2.  We added a facility for giving more explicit, descriptive error messages,
which has been used in many places where the the user would otherwise just
receive NS_ERROR_FAILURE and have no idea why.  This can be augmented further by
adding better error handling in any non-bug case where the script caller gets an
error message that is not helpful enough.

Remaining issues:

3.  If the document is not successfully parsed, then the real server output
(especially where the server returned HTML instead of XML) is not displayed.  we
will need to add attributes to SOAPCall to make this possible, or issue 4 could
solve this, too, by additional output.4.  It would be nice if the user didn't
have to compile debug or find the console to see the messages exchanged with the
server.  I welcome opinions on whether it is always appropriate to show the
exchange on the JS console, since in an application that used SOAP heavily, this
might make the JS console unusable for other purposes.
5.  I can look into issues with the JS debugger, although (2) and (4) seem to me
to be the easiest ehancements with thee least work.  I am not very experienced
with the JS debugger.  If issues with the JS debugger are due to something the
SOAP implementation is doing wrong, that is one thing, but if it is due to
something else it would have to be a seperate bug and effort.

Comment 3

[Michael Percy (obsolete email address)]

I don't know how difficult it would be to implement a callback like I mentioned,
especially since it would probably be something like a JS function callback
referenced within C++ code. If that is a pain to implement, maybe setting a
property like dumpWire would work (it could dump all data sent and recieved w/
that object to the JS console). soap.dumpWire = 0 would be the default, setting
it to 1 would enable it.

The bad thing about compiler flags is that client developers on NS and even Moz
builds will never be able to use those non-default features. This effectively
renders it useless to anyone but Mozilla.org developers.

Comment 4

[Ray Whitmer]

I agree that relying on a compiler flag and sending it to stdout is not a good
idea, and we should find out how to get away from that.  I do not believe that a
callback helps significantly, nor do I want a global soap object.  For the
low-level SOAP APIs, it is fairly simple to get the value of the message before
invoking it and sending it wherever you like.  Just serialize the document.  The
same is true of the response except in the one case where the parsing fails.  We
can add an accessor to get back the text of the message in case the parsing failed.

It would be nice to be able to turn on logging to the JS console, as well as
fixing any bugs there may be in the JS debugger when using SOAP objects.  As I
think of the use cases for callbacks taking into account security and so on, the
callback on top of logging does not seem to value proportional to the difficulty
of adding and using it, but perhaps I am missing something.

Comment 5

[Michael Percy (obsolete email address)]

Now that you mention it, an accessor method would probably be a more
straightforward and easy way to get debug info. I'm not sure how useful
callbacks as an implementation really are in this case... an event-based model
is not really ideal here, I have just seen it done that way in other
implementations. I think they just hooked it right on top of the transport layer
and called back whenever any data was transferred.

Another cool thing I just thought of about implementing a JS interface to these
messages is that in a DHTML-based SOAP app, the client programmer can choose to
store/display the SOAP wiredump formatted however he likes, even log them back
to a talkback-like SOAP API when exceptions occur. Sweet!

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

harishd is now the SOAP owner, reassigning.

Comment 7

[John Gaunt (redfive)]

With all the work going on in Web Services now, including things like WSDL
support in Moz, putting together XSLT transforms to make WSDL readable, and
testcase generators to test Web Services it seems we now have need for something
a little stronger than js alerts to debug our Web Service/SOAP efforts. I'm
going to start looking into creating a Web Services Console that will wrap the
stuff we have under way now with some logging of SOAP calls.

Comment 8

[John Gaunt (redfive)]

taking SOAP bugs

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

We dropped SOAP.