Hmm. Looking a little deeper, I find that I'm not really using the new
Xen API calls, but in fact, the older xml-rpc interface. I guess I
have some work to do to get my code running using the correct calls.
After looking at the code in XendAPI.py, VM.unpause will end up
returning xen_api_success_void(), which will not be a nil. It is only
the older api that was returning None directly, which resulted in
<nil> in the xml-rpc response. My bad.
-Ray
On 3/29/07, Ray Kelm <kelmray@xxxxxxxxx> wrote:
I'm sorry, I should have been more clear. Apache xml-rpc has support
for vendor extensions, which violate the original xml-rpc spec. In
order for them to be enabled, their client library negotiates with the
server implementation, and only if both sides have extensions enabled
does it support them. The expected situation is that if a non-apache
client accesses an apache server, it won't ask for extensions, so the
server will not use them. If an apache client accesses an non-apache
server, the negotiation is ignored, so the client disables the
extensions.
One of those extensions is support for returning a null value (or
python's None in this case) as <nil> or maybe <ex:nil>. The python
xmlrpc code does this apparently by default, when you call a method
that has no return value, for example, xend.domain.unpause.
Here's some information about the extensions supported by apache's
library. http://ws.apache.org/xmlrpc/extensions.html
In the end, I was unable to get it to work because xend wasn't
responding in a way that apache recognized, so it was disabling
extensions. I had to add a custom handler for <nil> using a class
based on TypeFactoryImpl, which solved the problem nicely.
-Ray
On 3/29/07, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
> Ray Kelm wrote:
> > I've had some success using the apache xml-rpc library to access xen
> > with version 3.0.4. There were a few gotchas, such as having to enable
> > extension support because xend was sending back nil as a result, which
> > is only valid if extensions are enabled. Unfortunately, it appears
> > that xend was not honoring the fact that extension support is
> > negotiated.
>
> Extension support isn't negotiated (at least, not by any API I know of).
> Do you have a reference for this?
>
> Regards,
>
> Anthony Liguori
>
>
> > It would be handy to have a packaged solution that exports a simple
> > api for talking to xend, as building some of the control structures is
> > a bit of a pain.
> >
> > -Ray
> >
> >
> > On 3/29/07, Premjith Rayaroth <premjith.rayaroth@xxxxxxxxxx> wrote:
> >> Hi,
> >>
> >> Is Java support available for Xen APIs. Can I use Java to make XML-RPC
> >> calls to the Xen machines? I assume only 'C' and 'Python' are supported.
> >> Is there any plan to support Java.
> >>
> >> Thanks
> >> -Prem
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-devel
> >>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home