Edit report at http://bugs.php.net/bug.php?id=49169&edit=1
ID: 49169
Comment by: rkm at nykredit dot dk
Reported by: jeroen at asystance dot nl
Summary: SoapServer calls wrong function, although "SOAP
action" header is correct
Status: Verified
Type: Bug
Package: SOAP related
Operating System: linux
PHP Version: 5.2SVN-2009-08-05 (snap)
Block user comment: N
New Comment:
Well, maybe the RPC-protocol will work, but where I work, it is
mandatory to create services using style="document", and it really isn't
to the advantage of PHP to tell the servicepeople in the Java dept. that
we can't handle "document" styles.
Actually I circumvented the problem, by putting all the message
definitions in separate files, which I then include in the schema-part
of the wsdl.
Then PHP can handle the soap:binding style="document" just fine, so the
problem only occurs if the names are duplicated within the same file.
Previous Comments:
------------------------------------------------------------------------
[2010-09-08 13:54:12] hoffmeister dot c at gmx dot de
This is no bug. I guess you used style="document" in the wsdl file
operation description. In this case there is no operation name passed
from the client to the server. Try style="rpc" (remote procedure call)
instead. That works pretty well.
------------------------------------------------------------------------
[2010-03-30 12:19:42] rkm at nykredit dot dk
Adding to the above comment - If first SoapServer fails to read your
WSDL properly, it will end up calling all known methods of the object
added to SoapServer.
- By "known" I mean, that if the .wsdl describes *another* binding to
*another* method, than the one called - The other method gets called as
well, and the result added to the <SOAP-ENV:Header> tag in the return.
------------------------------------------------------------------------
[2010-03-30 11:03:12] rkm at nykredit dot dk
It's not even enough to change the message name (I didn't get that from
the initial comments) - One needs to change the element of the part.
Thus
<wsdl:message name="getByIdRequest">
<wsdl:part name="parameters" element="tmp:ClientId"/>
</wsdl:message>
Will not work with (reusing tmp:ClientId):
<wsdl:message name="getByIdRequest2">
<wsdl:part name="parameters" element="tmp:ClientId"/>
</wsdl:message>
You'll have to create a new element, wich makes it hard to use i a
corporate environment, where you have to use standard elemnts - Thus
this is not a valid option, even though it works:
<wsdl:message name="getByIdRequest2">
<wsdl:part name="parameters" element="tmp:ClientId_Clone"/>
</wsdl:message>
This bug has been here for a while, any movement against a solution?
So far I have to create a WSDL for each operation, which is not very
PHP-smooth!
------------------------------------------------------------------------
[2009-11-04 17:08:04] spyowl at gmail dot com
Confirmed on 5.3.1RC3 using WSDL.
The problem seems to be the matching first argument name between methods
(not the whole signature) - as long as 2 or more methods have the same
name for the first argument the SoapServer will always execute the first
method listed, regardless of soapAction, and even if there are
additional arguments for those methods that are different from each
other.
This is a pretty serious bug.
------------------------------------------------------------------------
[2009-09-30 06:58:28] wee at xbe dot ch
this bug is really annoying.. the forced use of rpc (the "workaround")
is not a serious fix.
we also evaluated wso2 (wsf_php) as the php soapserver simply isn't that
business ready, but that too has it's issues (has problems when it comes
to generate complex wsdl and with complex type handling on the php
side). and it segfaults with an activated zend optimizer+ ;-)
anyway, i just comment to give more importance to this bug.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=49169
--
Edit this bug report at http://bugs.php.net/bug.php?id=49169&edit=1
