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@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
___
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
