in reply to troubles writing mod_soap clients

Found the problem!

First off, thanks to chromatic for the tip - turns out that my build of Apache was not linked with expat.

RedHat7.0 includes an rpm of expat-1.95, i erased it and built expat from source. Then i rebuilt Apache and mod_perl and mod_soap is now a happy camper!

Update: Aug 28, 2001
I broke it again!!! Looks like XML::Parser was using my expat rpm, so i reinstalled XML::Parser and sometime later i noticed that mod_soap was broken again.

This time maverick came to my rescue and showed me Apache ToolBox.

During install, ToolBox gives you an opportunity to configure the Apache installation config file - i added this line:

--disable-rule=expat \
which (roughly) tells Apache not to use expat-lite (which is used by default).

jeffa

Replies are listed 'Best First'.
Re: (jeffa) Re: troubles writing mod_soap clients
by rob_au (Abbot) on Aug 21, 2003 at 13:59 UTC
    Thanks for the follow-up on this jeffa - I just ran into this one myself and your post was quite instrumental in helping me solve my own dilemma. I did come across one additional issue which may be of interest to others with regard to the specification of service dispatch within the configuration in the httpd.conf file.

    Where the service dispatch is specified in a dynamic manner, @INC is disabled and as such modules outside of the service dispatch location are unavailable to the script. As a result, I found that the following mixed pattern for service dispatch specification was more flexible with regard to permitting access to both service location and core/installed modules.

    # Dynamic service dispatch specification <Location /trusted_delivery> SetHandler perl-script PerlHandler Apache::SOAP PerlSetVar dispatch_to "/usr/local/soap-app" </Location> # Mixed service dispatch specification <Location /trusted_delivery> SetHandler perl-script PerlHandler Apache::SOAP PerlSetVar dispatch_to "/usr/local/soap-app, MyApp" </Location>

    Besides this obvious advantage of access to core and installed modules with mixed service dispatch specification, this approach also allows you to limit what code within the service dispatch location is accessible from the SOAP interface.

    There was another really obscure error which I did also come across with regard to permission to access classes within the service dispatch location, but unfortunately, I haven't been able to replicate this to explain it's causation fully.

     

    perl -le 'print+unpack"N",pack"B32","00000000000000000000001001111101"'