Closed
Bug 129654
Opened 22 years ago
Closed 14 years ago
Need better facilities to debug SOAP calls
Categories
(Core Graveyard :: Web Services, defect)
Core Graveyard
Web Services
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: mpercy, Unassigned)
Details
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.
Reporter | ||
Comment 1•22 years ago
|
||
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•22 years ago
|
||
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Reporter | ||
Comment 3•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 5•22 years ago
|
||
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!
Updated•22 years ago
|
QA Contact: petersen → rakeshmishra
harishd is now the SOAP owner, reassigning.
Assignee: rayw → harishd
Status: ASSIGNED → NEW
Comment 7•21 years ago
|
||
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.
Updated•21 years ago
|
Component: XML → Web Services
Updated•17 years ago
|
Assignee: mozilla → nobody
QA Contact: rakeshmishra → web-services
We dropped SOAP.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•