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>
[download]

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"'