Loading ...
Sorry, an error occurred while loading the content.

Re: How do I add custom trace callbacks?

Expand Messages
  • Petar Shangov
    Hi, thanks to everyone who responded. ... rahed, the problem turned out to be that all the relevant tracing calls are made inside SOAP::Transport::HTTP::Client
    Message 1 of 9 , Mar 25, 2009

      thanks to everyone who responded.

      ----- Original Message ----
      > From: rahed <raherh@...>
      > To: Petar Shangov <pshangov@...>
      > Cc: soaplite@yahoogroups.com
      > Sent: Tuesday, 24 March, 2009 21:41:48
      > Subject: Re: [soaplite] How do I add custom trace callbacks?
      > Apparently you access your local server. I haven't tried this. When you
      > call a remote host you must get what you want, xml request & response.
      > I guess the trace is not enabled for your particular case or the service
      > is called wrongly.
      > For instance when calling
      > $soap = SOAP::Lite->new(
      > uri => ("http://www.webserviceX.NET"),
      > proxy => ('http://www.webservicex.com/globalweather.asmx' ),
      > );
      > the trace is like this:
      > ...


      the problem turned out to be that all the relevant tracing calls are made inside SOAP::Transport::HTTP::Client and so this code does not work when S::L is used as a server, which is my case.

      ----- Original Message ----
      > From: Peter Farr <Peter.Farr@...>
      > To: Petar Shangov <pshangov@...>
      > Sent: Tuesday, 24 March, 2009 20:43:13
      > Subject: Re: How do I add custom trace callbacks?
      > Peter, I typed this response into the Yahoo group but I haven't seen it
      > show up yet, so here it is again:
      > I can get your daemon to print to a log and to stdout with the following
      > change:
      > use SOAP::Lite +trace => [ all =>
      > sub {
      > open LOGFILE,">>trace.log";
      > print LOGFILE "This:" . $_[0] . "\n";
      > close LOGFILE;
      > warn("This:" . $_[0] . "\n");
      > }
      > ];
      > When I change "all" to "debug" it stops working, but "transport" (or any
      > other valid value) works okay. I suspect a conflict between debug and
      > the SOAP::Transport::HTTP::Daemon code. I don't know what is causing it,
      > but you could always file a bug and see what happens.


      I got this to work, but it still did not print out the request and response strings. The 'debug' option does not work since when used as a server, S::L encounters no calls to SOAP::Trace::debug() during its lifetime. I ended up inserting these calls manually, and submitted a bug report (https://rt.cpan.org/Ticket/Display.html?id=44568).

      > From: Lee Carmichael <lecar_red@...>
      > To: Petar Shangov <pshangov@...>; soaplite@yahoogroups.com
      > Sent: Wednesday, 25 March, 2009 19:37:40
      > Subject: Re: [soaplite] Re: How do I add custom trace callbacks?
      > Hello Petar,
      > After seeing your example, I just realized that you
      are trying to debug a server. Sorry my last post won't be much help
      since it seems that transport level debugging is a client only option.
      > It
      seems that most of the server code doesn't have any trace statements
      besides the empty create/destroy ones (you can see these as
      SOAP::Trace::trace( '()' ) ).
      > You tell what is traceable by
      looking through the code for SOAP::Trace::<signal>. For example
      in SOAP::Lite under the package SOAP::Server you can see an entry like:
      > SOAP::Trace::result(@results);
      > It seems that you could get information from parameters or results for servers. Which doesn't strike me as terribly helpful.
      > I
      did have an idea that i tested out. Since you said you were trying to
      debug request and responses, these will get passed to the deserializer
      and serializer. I was able to write a stub that logs the requests by
      sub classing the existing deserializer class into one that includes
      > Here is an example:
      > ...
      > I'm
      sure you could do something similar to SOAP::Transport::HTTP::Daemon by
      using a sub class to do custom processing of the accept and dumping out
      the request/response content. Maybe I'll look at that tonight.


      I received your mail just after I had posted a bug report. Your approach is probably safer in the long run since I am now using a locally modified version of S::L.

      On a side note, I need server debugging since I will be testing my server with various non-perl clients, and it is easier to do my testing on the perl side.


    Your message has been successfully submitted and would be delivered to recipients shortly.