Hi Achim,
I finally figured-out the problem!
So ... I was using the correct WSDLs, the correct generated PHP wrappers ...
and after much digging ... I finally realized that PHP by default has WSDL
caching enabled!
With caching enabled (that is the default setting in the php.ini file), the
WSDLs are cached for one day. After realizing this ... I disabled the caching
for my test [ini_set ("soap.wsdl_cache_enabled", "0")] and the call worked!
Thought I was loosing my mind on that one ... thanks for all your help.
Joe.
________________________________
From: Achim Hasenmueller <[email protected]>
To: Joseph Smith <[email protected]>
Cc: [email protected]
Sent: Thu, May 20, 2010 7:30:57 AM
Subject: Re: [vbox-dev] Deprecated webservice APIs in 3.2 ...
Joe,
I think you are calling getCPUProperty with its old name getCpuProperty
(capitalization).
As I said, we recommend querying the version after connecting to the API. We
cannot really version the API in a sensible way because the changes are not
done in a compatible manner, i.e. methods disappear and method signatures
change. For the Java bindings we used the package name space to allow you to
load several versions, I do not know enough about the PHP API to make any
statements. Maybe you can elaborate on your suggested change for PHP and Python?
I can understand your concern but the best answer I have is that you don't have
to follow every update. This is how we work with most large consumers of our
API. They migrate from VirtualBox 2.0 to 3.0, from 3.0 to 3.2, etc.
Virtualization is still a very dynamic market and innovation happens at rapid
pace but this will certainly cool down over time. This doesn't mean that we've
run out of ideas though :-)
Achim.
On May 20, 2010, at 13:19 , Joseph Smith wrote:
Hi Achim,
>
>Thanks for the quick reply.
>
>I definitely appreciate the need to keep a clean design and applaud that.
>Since the VirtualBox development team is so good at cranking out enhancements
>... major version releases happen rather quickly (for 3.1.x to 3.2.0 it's only
>been about 5 or 6 months). At that pace, it means an average or twice a year
>the API consumer community can expect to see a major release that could have a
>significant impact ... hmmm ... this could be a challenge in larger
>implementations as some deployment cycles may not be that quick.
>
>My suggestion (actually a request) for having the version number be part of
>the generated modules was also an attempt at ensuring the middle layer (PHP,
>Python and other generated API interfaces) along with the WSDLs are a
>compatible or known version. Since WSDL and generated filenames do not
>change, the only way to determine a difference is to diff a known file against
>another known file ... not the most elegant way to do that.
>
>With no embedded 'version' elements, it makes it impossible to programatically
>ensure the generated modules we are using match the version of the APIs
>themselves.
>
>Do you have any information on the IMachine::getCPUProperty API? That API per
>the 3.2 documentation appears to still be supported ... but an attempt to call
>that API results in the exception I noted below.
>
>
>Thanks,
>Joe
>
>
>
>
________________________________
From: Achim Hasenmueller <[email protected]>
>To: Joseph Smith <[email protected]>
>Cc: [email protected]
>Sent: Thu, May 20, 2010 5:16:34 AM
>Subject: Re: [vbox-dev] Deprecated webservice APIs in 3.2 ...
>
>
>Joe,
>
>
>the policy is that when we do a major update (first and/or second digit
>change, 3.2 is one), we may change APIs in incompatible ways. This is is a
>burden on the API consumer but it allows us to keep a clean design and not
>accumulate legacy. Within one major version (e.g. 3.1.x), we guarantee API
>stability.
>
>
>Regarding versioning, the first call you make should be to query the
>VirtualBox version number. Then you know which API is in place and in your
>code, you should differentiate between versions and make the appropriate calls.
>
>
>Ideally, we document all API changes in the SDK manual but unfortunately that
>didn't happen for the 3.2.0 release. Some of the changes are explained
>(section 7.5) but it's not complete. We will address this for the upcoming
>3.2.2 service release.
>
>
>The IGuest::getStatistics stuff is gone in 3.2 as it was a Windows guest only
>temporary solution that got finally folded into the more generic metrics API.
>
>
>A good way to see what has changed is to diff VirtualBox.xidl which is the
>abstract definition of our API. You can find the trunk version here:
>http://www.virtualbox.org/browser/trunk/src/VBox/Main/idl/VirtualBox.xidl
>Just diff the one from the 3.2.0 tarball and the one from 3.1.8 to get an idea.
>
>
>Achim
>
>
>
>On May 20, 2010, at 10:27 , Joseph Smith wrote:
>
>Hi,
>>
>>
>>I am currently using VBox 3.1.6 webservice APIs (PHP version) and decided to
>>make the jump to version 3.2 (skipping 3.1.8) as I thought it was time to
>>'get caught up'.
>>
>>
>>In doing so, I got caught by a few surprises. I have only begun initial
>>testing ... here is what I've found thus far:
>>
>>
>>1) IMachine::getCPUProperty throws the following exception:
>>Method 'ns1:IMachine_getCpuProperty' not implemented: method name or
>>namespace not recognized). The method is described in the WSDL and so is the
>>CPUPropertyType. PHP API wrappers also appears to be correct. Was this
>>method deprecated?
>>
>>
>>2) IGuest::getStatistic (required a parm of 'GuestStatisticType') does not
>>seem to be a valid method any more. Appears to have been replaced with
>>IGuest::internalGetStatistics. From the 3.2 API docs ... seems this method
>>is intended to only be called internally? What does 'internal' mean here? I
>>am assuming the getStatistic method was deprecated?
>>
>>
>>3) IDisplay::getWidth, IDisplay::getHeight and IDisplay::getBitsPerPixel do
>>not seem to be valid any more. Appears to have been replaced with
>>IDisplay::getScreenResolution. I'm guessing here the width, height and bpp
>>elements were depricated?
>>
>>
>>Thinking I missed something ... I went back and looked at the 3.1.8 docs to
>>find where deprecated functions were listed ... and found the usual
>>IVirtualBox::createLegacyMachine and IVirtualBox::openMachine listed ... but
>>nothing else.
>>
>>
>>Some questions:
>>1) Where are deprecated and 'planned to be deprecated' APIs and
>>fields/elements listed? Is it somewhere else I should have checked?
>>
>>
>>2) What is the deprecation policy? How far in advance will APIs be advised
>>of deprecation?
>>
>>
>>3) Generally ... when APIs are deprecated ... they are supported for N past
>>versions ... what is the past-version-support and 'roll-off' duration for
>>deprecated APIs?
>>
>>
>>I am trying to identify a proactive way in detecting changes to APIs that my
>>solution uses so that I don't have to suddenly react for a new release. Is
>>there some other documentation that details all this and I'm just not aware
>>of it? This is not the first time ... a similar situation happened when the
>>more robust and better IMedium and IStorageController approach was added.
>>
>>
>>May I make a suggestion:
>>WSDL files and the vboxServiceWrappers.php file do not appear have any
>>'version' related information that could allow an application to be "smarter"
>>about what APIs are available. Can versioning be added to the WSDL files
>>that correlate somehow to the API version? Maybe an enumerated list of
>>releases of the VirtualBox application that the WSDL supports ... or even a
>>simple comma separated list of versions? That way, the generated
>>vboxServiceWrappers.php module (and other generated modules) would also
>>include that information. It could go a long way in allowing applications to
>>use the version information to make 'smart' decisions about which APIs or
>>features are available or not.
>>
>>
>>
>>
>>Thanks,
>>Joe
>>
>>
>>_______________________________________________
>>vbox-dev mailing list
>>[email protected]
>>http://vbox.innotek.de/mailman/listinfo/vbox-dev
>>
>
>
>
>
>
>
--
Achim Hasenmueller
Director Engineering, VirtualBox
Sun Microsystems GmbH
Werkstrasse 24
71384 Weinstadt, Germany
phone: +49 7151 604050
================================================
Sitz der Gesellschaft: Sun Microsystems GmbH,
Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Jürgen Kunz
================================================
_______________________________________________
vbox-dev mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-dev
