Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.14.0

Bug #16968 Bad array assignment when using WSDL client
Submitted: 2010-01-05 09:26 UTC
From: bblough Assigned: yunosh
Status: Closed Package: SOAP (version 0.12.0)
PHP Version: 5.2.5 OS: Debian GNU/Linux 5.0 (Lenny)
Roadmaps: (Not assigned)    
Subscription  


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 32 - 1 = ?

 
 [2010-01-05 09:26 UTC] bblough (Bill Blough)
Description: ------------ When using SOAP_Client to consume a particular WSDL-based web service, I receive the error Warning: Invalid argument supplied for foreach() in /usr/share/php/SOAP/Client.php on line 586 and , the client fails to build the outgoing message correctly. It appears that Client.php:586 is expecting an array, but receiving a string. Upon further investigation, I determined that SOAP_WSDL->getOperationData() is attempting to assign a populated array to a scalar varable instance. I don't know if this is case where the scalar in question should never be scalar (indicating an issue elsewhere, perhaps when parsing the WSDL), or if there simply needs to be a check to handle this case. I'm going to assume for the moment that it's the latter, and have a patch. If this isn't the correct approach, perhaps someone with more knowledge oif the code will have some ideas. I have also attached the WSDL. Test script: --------------- $url="localhost/WeatherAttachmentWeb/services//WeatherAttachment/wsdl/WeatherAttachment.wsdl"; $action = "getDayForecastImage"; $attachment = "please.gif"; $bgImage = new SOAP_Attachment('bgImage','image/gif', $attachment); $theDate = new SOAP_Value('theDate', 'dateTime', date("c",time())); $client = new Soap_Client( $url, true ); $options = array( 'trace' => true, 'attachments' => 'Mime' ); $resp = $client->call( $action, array( 'theDate' => $theDate, 'bgImage' => $bgImage ) ), $options); if (PEAR::isError($resp)) { echo $resp->getMessage()."\n"; } //WSDL attached Expected result: ---------------- WSDL.php: $opData['input']['parts'] returned from getOperationData() [parts] => Array ( [theDate] => Array ( [name] => theDate [type] => dateTime [namespace] => xsd ) [bgImage] => Array ( [name] => bgImage [type] => hexBinary [namespace] => xsd ) ) Actual result: -------------- WSDL.php: $opData['input']['parts'] returned from getOperationData() [parts] => AheDate

Comments

 [2010-01-05 09:30 UTC] bblough (Bill Blough)
 [2010-01-05 09:36 UTC] bblough (Bill Blough)
OK, I was intending to attach the WSDL, but I don't see how to do that. I'm guessing I shouldn't add it as a patch, nor should I just paste i100 lines into a comment.
 [2010-01-06 17:00 UTC] yunosh (Jan Schneider)
Add a .txt extension to the wsdl file, then upload it as a patch. That should work.
 [2010-01-07 00:35 UTC] bblough (Bill Blough)
 [2010-02-24 04:53 UTC] bblough (Bill Blough)
 [2010-02-24 04:56 UTC] bblough (Bill Blough)
I ran into an issue where the previous patch was causing problems. Specifically, an empty named parameter which would cause WSDL operation to fail. I've submitted a new version of the patch to correct for this case. It resolves the issue for me, however I'm still not sure the overall solution is the correct one.
 [2010-02-24 04:59 UTC] bblough (Bill Blough)
Apologies - I was too hasty in my submission. The above should read - I ran into a situation where the previous patch was causing problems. Specifically, an empty named parameter was being added, which would cause resulting SOAP call to fail. I've submitted a new version of the patch to correct for this case. It resolves the issue for me, however I'm still not sure the overall solution is the correct one.
 [2010-03-17 23:22 UTC] yunosh (Jan Schneider)
-Status: Open +Status: Closed -Assigned To: +Assigned To: yunosh
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.