[vbox-dev] Possibly non-documented incompatibility 4.x -> 5.0

[Maxime Dor]

Klaus,

Thank you for the clarification. With your explanations and looking at 
my code again, I see that I wasn't precise enough in my code.
The code that broke in 5.0 was this one, line 56 
<https://github.com/hyperbox/vbox-4.3/blob/master/src/server/core/src/io/kamax/vbox4_3/setting/console/VrdePortSettingAction.java#L56> 
- while in 4.x, the IConsole object always existed, regardless if the VM 
was running or not, it is no longer the case in 5.0
As you said, even if IConsole was created, all its attributes were null.

I definitely should have made a different check here - VM state instead 
of null on VRDEServerInfo - which lead me to get an unexpected NPE.
Maybe a short-coming of my understanding of the VBox API at the time of 
writing that code (a year ago or so), or maybe the doc is not precise 
enough of when IConsole should exist.
I can't tell at this point and I'll leave you judge of that.

Thank you for the clarifications, I see now I need to adapt my code to 
be better at least.

Max


On 27-07-15 10:50, Klaus Espenlaub wrote:
> Max,
>
> On 25.07.2015 01:03, Maxime Dor wrote:
>> Hi,
>>
>> It looks like in 5.0 the ISession::console attribute is no longer
>> created under a Shared or Write lock, but only on a VM lock.
>> In previous versions of VirtualBox, the console was always available
>> regardless of the lock type.
> Yes, but the sub-objects of IConsole were already all NULL for non-VM
> locks previously. Since everything worth using by a non-VM API client
> has been moved out of IConsole in 5.0 I'm a but surprised that this
> causes inconvenience.
>
>> This change is not documented in the SDK where you would expect it:
>> - IConsole class description
>> - ISession class description
> Negative documentation is generally considered bad style. In this case I
> really don't see the need, as in 5.0 there is absolutely nothing in
> IConsole which should be used by a "normal" API client. If there's no
> need to use IConsole, why should the attribute be non-NULL?
>
>> - Main API change log
>   From my perspective the first bullet item in the change log describes
> everything vital for someone who needs to adjust API clients.
>
> Could you explain a bit more what kind of (for me unexpected) issues you
> ran into?
>
>> The only info is in the ISession::console attribute description.
>>
>> Is this change expected? Or are there other subtleties in play?
> This change is entirely expected, and is the long awaited final step
> which makes it possible to e.g. take, delete or restore snapshots from a
> 32 bit API client on a 64 bit host (which often sabotaged people who
> wanted to use the python API binding on Windows).
>
> Previously this was impossible as it was only implemented in the 64 bit
> variant of the corresponding library which lives in the client process.
>
> It also created the paradoxical situation that the (now moved)
> operations were not implemented by the API service in VBoxSVC, but were
> effectively offered by the first API client which happened to be there
> (so if the VM manager GUI happened to have a session open for a specific
> VM, it would e.g. be responsible for handling snapshot operations, which
> could easily fail if it went away shortly after).
>
> In many ways it's the long awaited correction of a very very old API
> design flaw.
>
> Klaus
>
>> Thank you for the clarification.
>>
>> Max
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20150727/79d297a2/attachment.html>