|  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.1 ± 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: Closed Package: SOAP related
PHP Version: 5.6.7 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: champetier dot etienne at gmail dot com
New email:
PHP Version: OS:


 [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 '\'.
 [2024-06-01 11:32 UTC]
Automatic comment on behalf of nielsdos (author) and web-flow (committer)
Log: Fix bug #69280: SoapClient classmap doesn&#039;t support fully qualified class name (#14398)
 [2024-06-01 11:32 UTC]
-Status: Open +Status: Closed
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jun 25 02:01:28 2024 UTC