On Sun, Apr 15, 2007 at 10:07:01PM +0100, Daniel P. Berrange wrote:
> The virError() class in the python bindings will either pick up the global
> error details, or will extract them from the virConnect private error
> details. For the latter to work, you must pass in a virConnect object
> when creating the virError. I'd previously fixed up the generator so that
> was done correctly for any method on virConnectPtr, however, I forgot that
> a similar fix was needed for the virDomainPtr / virNetworkPtr related
> methods. Currently we're getting back zero useful information in the python
> layer with a virDomain* or virNetwork* method fails.
Hum, I see, problematic ...
> Unfortunately, given a virDomainPtr / virNetworkPtr object in python, there
> is no easy way to get back the virConnectPtr object. So this patch does
> two things - it passes the virConnect python object into the constructor
> of the virDomain / virNetwork python objects, and then stores it in a
> private _conn attribute. Then, the virNetwork/virDomain objects are passed
> into the virError() classes when needeed so it can get hold of the private
> error details.
>
> So with this patch, virt-manager will get sensible error information when
> attempting to start an inactive guest, or when doing device hot-add/remove.
[...]
> BTW, since we now store an explicit reference to the virConnect object,
> I removed the generic 'self.ref' back-reference.
> -classes_references = {
> - "virDomain": "virConnect",
> - "virNetwork": "virConnect",
> -}
> -
> functions_noexcept = {
> 'virDomainGetID': True,
> 'virDomainGetName': True,
> @@ -872,11 +867,16 @@ def buildWrappers():
> else:
> txt.write("Class %s()\n" % (classname))
> classes.write("class %s:\n" % (classname))
> - classes.write(" def __init__(self, _obj=None):\n")
> + if classname == "virDomain" or classname == "virNetwork":
> + classes.write(" def __init__(self, conn, _obj=None):\n")
> + else:
> + classes.write(" def __init__(self, _obj=None):\n")
the generator is getting more and more hackish :-\
I understand the reasons though... I'm resisting ditching it because we are
still changings APIs an comments quite a bit, one day it won't be worth keeping
it.
Please go ahead,
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/