SOAP - TROUBLESHOOTING

TROUBLESHOOTING ^

SOAP::Lite serializes "18373" as an integer, but I want it to be a string!

    SOAP::Lite guesses datatypes from the content provided, using a set of common-sense rules. These rules are not 100% reliable, though they fit for most data.

    You may force the type by passing a SOAP::Data object with a type specified:

     my $proxy = SOAP::Lite->proxy('http://www.example.org/soapservice');
     my $som = $proxy->myMethod(
         SOAP::Data->name('foo')->value(12345)->type('string')
     );

    You may also change the precedence of the type-guessing rules. Note that this means fiddling with SOAP::Lite's internals - this may not work as expected in future versions.

    The example above forces everything to be encoded as string (this is because the string test is normally last and always returns true):

      my @list = qw(-1 45 foo bar 3838);
      my $proxy = SOAP::Lite->uri($uri)->proxy($proxyUrl);
      my $lookup = $proxy->serializer->typelookup;
      $lookup->{string}->[0] = 0;
      $proxy->serializer->typelookup($lookup);
      $proxy->myMethod(\@list);

    See SOAP::Serializer for more details.
+autodispatch doesn't work in Perl 5.8

    There is a bug in Perl 5.8's UNIVERSAL::AUTOLOAD functionality that prevents the +autodispatch functionality from working properly. The workaround is to use dispatch_from instead. Where you might normally do something like this:

       use Some::Module;
       use SOAP::Lite +autodispatch =>
           uri => 'urn:Foo'
           proxy => 'http://...';

    You would do something like this:

       use SOAP::Lite dispatch_from(Some::Module) =>
           uri => 'urn:Foo'
           proxy => 'http://...';

Problems using SOAP::Lite's COM Interface

    Can't call method "server" on undefined value

        You probably did not register Lite.dll using regsvr32 Lite.dll
    Failed to load PerlCtrl Runtime

        It is likely that you have install Perl in two different locations and the location of ActiveState's Perl is not the first instance of Perl specified in your PATH. To rectify, rename the directory in which the non-ActiveState Perl is installed, or be sure the path to ActiveState's Perl is specified prior to any other instance of Perl in your PATH.

Dynamic libraries are not found

    If you are using the Apache web server, and you are seeing something like the following in your webserver log file:

      Can't load '/usr/local/lib/perl5/site_perl/.../XML/Parser/Expat/Expat.so'
        for module XML::Parser::Expat: dynamic linker: /usr/local/bin/perl:
        libexpat.so.0 is NEEDED, but object does not exist at
        /usr/local/lib/perl5/.../DynaLoader.pm line 200.

    Then try placing the following into your httpd.conf file and see if it fixes your problem.

     <IfModule mod_env.c>
         PassEnv LD_LIBRARY_PATH
     </IfModule>

SOAP client reports "500 unexpected EOF before status line seen

    See "Apache is crashing with segfaults"
Apache is crashing with segfaults

    Using SOAP::Lite (or XML::Parser::Expat) in combination with mod_perl causes random segmentation faults in httpd processes. To fix, try configuring Apache with the following:

     RULE_EXPAT=no

    If you are using Apache 1.3.20 and later, try configuring Apache with the following option:

     ./configure --disable-rule=EXPAT

    See http://archive.covalent.net/modperl/2000/04/0185.xml for more details and lot of thanks to Robert Barta <[email protected]> for explaining this weird behavior.

    If this doesn't address the problem, you may wish to try -Uusemymalloc, or a similar option in order to instruct Perl to use the system's own malloc.

    Thanks to Tim Bunce <[email protected]>.
CGI scripts do not work under Microsoft Internet Information Server (IIS)

    CGI scripts may not work under IIS unless scripts use the .pl extension, opposed to .cgi.
Java SAX parser unable to parse message composed by SOAP::Lite

    In some cases SOAP messages created by SOAP::Lite may not be parsed properly by a SAX2/Java XML parser. This is due to a known bug in org.xml.sax.helpers.ParserAdapter. This bug manifests itself when an attribute in an XML element occurs prior to the XML namespace declaration on which it depends. However, according to the XML specification, the order of these attributes is not significant.

    http://www.megginson.com/SAX/index.html

    Thanks to Steve Alpert ([email protected]) for pointing on it.
 

source: http://search.cpan.org/~phred/SOAP-Lite-1.20/lib/SOAP/Lite.pm#TROUBLESHOOTING