Hi Volker, That was a great catch, and a very detailed write up of the problem. I agree, since the library is handling class loading on its own it's probably best to disable the autoload feature of that method. Would you mind creating an bug for this on the library's issue tracker?
http://code.google.com/p/google-api-adwords-php/issues/ In the future it may be best to post bugs and feature requests there directly, and leave the forum for questions and discussions. You mentioned you are using Symfony, are you running into the same problem as this other user? http://code.google.com/p/google-api-adwords-php/issues/detail?id=4 Best, - Eric Koleda, AdWords API Team On Jan 18, 6:37 pm, Volker Kueffel <volker.kuef...@gmail.com> wrote: > Hi, > > When starting to use the PHP client library I encountered a somewhat > confusing issue: > > I tried to create a few dummy campaigns in my sandbox and got the > following error: > > Fatal error: Uncaught SoapFault exception: [soap:Server] Unmarshalling > Error: Unable to create an instance of > com.google.ads.api.services.campaignmgmt.campaign.v200909.jaxbgen.BiddingSt > rategy > in /adwords_client/src/Google/Api/Ads/Common/Lib/AdsSoapClient.php: > 160 > > However the examples that come with the client distribution actually > worked fine out of the original unzipped directory. When digging > deeper into this I noticed that I was actually using the v200906 > CampaignService in my app, although I requested v200909 from the > factory. The namespace inside the XML request document was correctly > set tohttps://adwords.google.com/api/adwords/cm/v200909though. And I > found the code was including the v200909 version of > CampaignService.php but still instantiating v200906. > > It turned out that the class loader was to blame. I was running this > application inside Symfony, but any other class loader that works in a > similar way would cause the same problem. CampaignService.php actually > defines a bunch of classes needed for the service's operation. In > order to avoid duplicate class names the code checks first, if a class > with that name already exists before running the class defintion which > looks like this: > > if (!class_exists("DateRange")) { > // definition of DateRange class > > } > > However this triggers the class loader to try and load that class, > which in my case found the v200906 version CampaignService.php, > included it and ran all the definitions inside the file. After that > all subsequent definitions in the v200909 version of > CampaignService.php where ignored. > > I'd suggest to change all the tests for existence of classes to > include the second parameter of class_exists and prevent the class > loader from being used; for the above example that would just require > a small change: > > if (!class_exists("DateRange",false)) { > // definition of DateRange class > > } > > Unless there is actually a reason why the code would want to load a > different class with that name of course. But from what I understand > that should only make sure the definition is not run twice. > > I know I can avoid that problem by just moving the client lib out of > the range of the class loader, which I did and everything worked as > planned. But I thought that little change could make the library a > little more robust. Depending on the efficiency of the class loader > that would also result in a tiny performance gain. > > Volker
-- You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-...@googlegroups.com. To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en.
