I could be reading this incorrectly but the API seems to
have a per-thread connection requirement which is unusual. This is
evidenced by the use of a ThreadLocal to maintain the URL/Session and that
EVERY API throws ConnectionHelper.NoConnectionOnThisThreadException.
So if threading is used on the client (Swing App) and the Xen objects ever
float between threads, issues are going to arise.
Number of Xen servers a client can connect to:
There is no obvious way for a client to connect to more than
one Xen server. This seems to be tied up with the threading issue.
There are other issues lurking here as well that relate to this – for example,
the various SoftReference caches are keyed by Object referenced ids which are
not guaranteed to be unique amongst a set of XenServers.
I think a preferable approach would be to make each Xen Object
(VM, host, etc) explicitly retain a reference to the session that was used to create
it (passed in via the constructor). A session to XmlRpcClient
mapping would be used to carry out API calls to the appropriate
server. Then all the threading and single server issues go
The various Record.toMap() APIs appear to return Maps of
Strings to Java Objects (sometimes these are collections of the various Xen
Objects, e.g. a Map returned by VM.Record.toMap contains “VIFs”
-> Set<VIF>. It would appear that these Maps could not be
used as parameters to create calls since they don’t contain XML
primitives as values. Ultimately the marshalling code would resolve
the values via toString, but no toString conversions to refids are provided.
The Java classes are in com.xensource.xenapi. Is
this an appropriate package given that the API was developed outside of Xensource
and not supported by XenSource? If the API was developed at the University of Cambridge, I would expect the code to be
in a university specific package.
295 Foster Street
(v) 978.489.1168 (f) 978.489.1101