|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69280 SoapClient classmap doesn't support fully qualified class name
Submitted: 2015-03-23 14:24 UTC Modified: -
Avg. Score:4.3 ± 0.9
Reproduced:6 of 6 (100.0%)
Same Version:1 (16.7%)
Same OS:2 (33.3%)
From: champetier dot etienne at gmail dot com Assigned:
Status: Open Package: SOAP related
PHP Version: 5.6.7 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
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 — but make sure to vote on the bug!
Your email address:
Solve the problem:
32 - 28 = ?
Subscribe to this entry?

 [2015-03-23 14:24 UTC] champetier dot etienne at gmail dot com
If you have in your wsdl an object that extends another one
(xs:extension)(RealClass1 extends AbstractClass in my case),
then your call will succeed (soap call containing xsi:type=RealClass1) if you have in your classmap:
'RealClass1' => 'RealClass1'
but will fail (RealClass1 casted to AbstractClass) if you have:
'RealClass1' => '\RealClass1'

Same thing with namespaces:
'RealClass1' => 'myNS\RealClass1' works
'RealClass1' => '\myNS\RealClass1' doesn't work

Test script:

Expected result:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:ns1="" xmlns:xsi="">
<ns1:testObj xsi:type="ns1:RealClass1">

(with xsi:type="ns1:RealClass1", and prop1)

Actual result:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:ns1="">

(testObj is downcasted from RealClass1 to AbstractClass and looses prop1)
(prop is a property of AbstractClass, prop1 property of RealClass1)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-02-16 16:24 UTC] vtsao at google dot com
I was going to file a bug for this as well, but found this one. Adding my notes as another data point.


I'm using SoapClient with a classmap specified in the options:

to map WSDL types to PHP classes. For example, I have a PHP class called NumberValue based on the NumberValue complexType defined in:

NumberValue has an abstract parent class called Value.

Thus, when passed in a SoapClient::__soapCall argument:

and converted into SOAP XML by PHP's SoapClient, it needs an xsi:type added to its node since it's a subclass. E.g.,

    <ns1:query>WHERE id = :id ORDER BY id ASC LIMIT 1</ns1:query>
      <ns1:value xsi:type="ns1:NumberValue">


The issue is that we're using a namespace for NumberValue and if we add a prefixing '\' in the SoapClient classmap to indicate global namespace like so:
array('NumberValue' => '\\Google\\AdsApi\\Dfp\\v201511\\NumberValue');

SoapClient doesn't seem to add the xsi:type on SOAP POSTs (outgoing SOAP calls), as it doesn't seem to be able to map the class to the WSDL type. On SOAP responses, it seems to map the WSDL type to class correctly as expected. E.g., it produces:

    <ns1:query>WHERE id = :id ORDER BY id ASC LIMIT 1</ns1:query>

If I remove the prefixing '\', it works. E.g.,
array('NumberValue' => 'Google\\AdsApi\\Dfp\\v201511\\NumberValue');

The prefix of '\' should not matter or affect the behaviour of SoapClient in this case right? Is this a bug?

A related bug is that it only supports global namespaces right now anyways:

But if the SoapClient classmap were ever to respect the declared namespace then it would need to work with a prefixing '\'.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Dec 01 01:03:34 2021 UTC