[libvirt] Re: Libvir-list Digest, Vol 32, Issue 7
I took at a look at that code. The JNI code is basically unchanged from the 0.1 version. The interesting part is the code is for handling the XML structures used by libvirt. You can see how Daniel Schweger's added functionality is meant to be used in the srtc/testclient/org/libvirt/TestXen.java file. The way I imagined the java-libvirt architecture is that there is a lower 'core' level, which is basically a function-for function equivalent of the C libvirt functionality, with the bare minimum of object-orientedness thrown in to pass for a proper java library (the current libvirt in CVS) Plus, there should/can be anotherl API, that exposes the XML files as java objects with get/set functions, etc. (It's in the org.libvirt.schema package in Daniel Schweger's code) Optionally, there could be higher level API that uses the core and XML api, and provides a really clean java-style object model, but IO haven't given it much thought yet. I think these two or three layers should be clearly demarcated, maybe even shipped as separate packages, becuse anything that layers on more functionaity that what the current cvs provides represents design decisions that are not inherent to libvirt. One may not want to use the XML technology/object model/whatever that libvirt-java ships, but rather add their own XML handling stuff/ higher level abstractions on top of the core libvirt bindings. (for example, Daniel Schweger's code uses XMLBeans, my original idea was to use JAXB for the same purpose). BTW I am working on adding the core bindings for the storage stuff, but don't expect anything soon, as my day job is currently eating all my time. regards István libvir-list-request@redhat.com wrote:
Send Libvir-list mailing list submissions to libvir-list@redhat.com
To subscribe or unsubscribe via the World Wide Web, visit https://www.redhat.com/mailman/listinfo/libvir-list or, via email, send a message with subject or body 'help' to libvir-list-request@redhat.com
You can reach the person managing the list at libvir-list-owner@redhat.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of Libvir-list digest..."
Today's Topics:
1. Re: AW: beta libvirt-java port uploaded (Daniel Veillard) 2. AW: [libvirt] AW: beta libvirt-java port uploaded (Daniel Schwager) 3. storage_conf.c: In function 'virStorageSize' (Jaime Traver) 4. Re: storage_conf.c: In function 'virStorageSize' (Atsushi SAKAI)
----------------------------------------------------------------------
Message: 1 Date: Thu, 3 Jul 2008 12:29:04 -0400 From: Daniel Veillard <veillard@redhat.com> Subject: Re: [libvirt] AW: beta libvirt-java port uploaded To: Daniel Schwager <Daniel.Schwager@dtnet.de> Cc: libvir-list@redhat.com Message-ID: <20080703162903.GI1362@redhat.com> Content-Type: text/plain; charset=us-ascii
On Thu, Jul 03, 2008 at 12:10:40PM +0200, Daniel Schwager wrote:
Cool - there's an "official" port... http://comments.gmane.org/gmane.comp.emulators.libvirt/7118
sorry for my last port, i didn't watch this list in the last time ..
BTW there is a new one 0.1.2 with better portability and JPackage compatibility. I must admit i'm a bit lost by all the code in your tarball, there are changes to libvirt-java, even in code already included in 0.1.0 , and a lot of subtrees which seems only loosely coupled to libvirt. What are the diffs which should be applied to the cirrent 0.1.2 code base ? and what specifically should be added in libvirt-java CVS. The Beans support seems one of them (but i have no idea how it's supposed to be used). A bit of explanations would go a long way ;-)
Daniel
On Fri, Jul 04, 2008 at 09:23:36PM +0200, Tóth István wrote:
I took at a look at that code.
The JNI code is basically unchanged from the 0.1 version.
okay
The interesting part is the code is for handling the XML structures used by libvirt.
You can see how Daniel Schweger's added functionality is meant to be used in the srtc/testclient/org/libvirt/TestXen.java file.
The way I imagined the java-libvirt architecture is that there is a lower 'core' level, which is basically a function-for function equivalent of the C libvirt functionality, with the bare minimum of object-orientedness thrown in to pass for a proper java library (the current libvirt in CVS)
Okay so far i agree.
Plus, there should/can be anotherl API, that exposes the XML files as java objects with get/set functions, etc. (It's in the org.libvirt.schema package in Daniel Schweger's code)
Optionally, there could be higher level API that uses the core and XML api, and provides a really clean java-style object model, but IO haven't given it much thought yet.
I think these two or three layers should be clearly demarcated, maybe even shipped as separate packages, becuse anything that layers on more functionaity that what the current cvs provides represents design decisions that are not inherent to libvirt. One may not want to use the XML technology/object model/whatever that libvirt-java ships, but rather add their own XML handling stuff/ higher level abstractions on top of the core libvirt bindings. (for example, Daniel Schweger's code uses XMLBeans, my original idea was to use JAXB for the same purpose).
Ah, okay.... Well my perspective is that libvirt-java should include only parts which are directly releated to using libvirt on Java. I would really not try to reinvent or push any XML related APIs there, at least as part of libvirt bindings (I still have the scars from libxml2, believe me you don't want to push new XML APIs to programmers even specialized ones). But things like the XSD descriptiond might be useful generally, and IMHO are very tied to libvirt, so i think they are a good fit. the fact that there may be multiple environment to work on the XML files means to me that it's better left off, or maybe provided as a contribution on libvirt.org FTP site, but probably better not integrated, because different users are likely to do things differently. IMHO the key point of libvirt-java is to make sufficient bindings to allow Java developpers to integrate libvirt without pain, while trying to not force them into a specific model (at least not beyond what libvirt itself imposes). Also fitting into this model are build makefiles for other environment, I understand that for most Java developpers, configure and make are really foreign tools, so adding ant/Eclipse/... build recipes for the package also makes a lot of sense. What do you think ?
BTW I am working on adding the core bindings for the storage stuff, but don't expect anything soon, as my day job is currently eating all my time.
Okay, cool. BTW libvirt-java review for Fedora seems done now, https://bugzilla.redhat.com/show_bug.cgi?id=453119 so hopefully i should be able to push it to more people real soon now. I also got Solaris portability feedback from John Levon which I need to integrate, there is clearly some work left, but there is no rush :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Fri, Jul 04, 2008 at 09:23:36PM +0200, Tóth István wrote:
I took at a look at that code.
The JNI code is basically unchanged from the 0.1 version.
okay
The interesting part is the code is for handling the XML structures used by libvirt.
You can see how Daniel Schweger's added functionality is meant to be used in the srtc/testclient/org/libvirt/TestXen.java file.
The way I imagined the java-libvirt architecture is that there is a lower 'core' level, which is basically a function-for function equivalent of the C libvirt functionality, with the bare minimum of object-orientedness thrown in to pass for a proper java library (the current libvirt in CVS)
Okay so far i agree.
Plus, there should/can be anotherl API, that exposes the XML files as java objects with get/set functions, etc. (It's in the org.libvirt.schema package in Daniel Schweger's code)
Optionally, there could be higher level API that uses the core and XML api, and provides a really clean java-style object model, but IO haven't given it much thought yet.
I think these two or three layers should be clearly demarcated, maybe even shipped as separate packages, becuse anything that layers on more functionaity that what the current cvs provides represents design decisions that are not inherent to libvirt. One may not want to use the XML technology/object model/whatever that libvirt-java ships, but rather add their own XML handling stuff/ higher level abstractions on top of the core libvirt bindings. (for example, Daniel Schweger's code uses XMLBeans, my original idea was to use JAXB for the same purpose).
Ah, okay.... Well my perspective is that libvirt-java should include only parts which are directly releated to using libvirt on Java. I would really not try to reinvent or push any XML related APIs there, at least as part of libvirt bindings (I still have the scars from libxml2, believe me you don't want to push new XML APIs to programmers even specialized ones).
My thoughts exactly.
But things like the XSD descriptiond might be useful generally, and IMHO are very tied to libvirt, so i think they are a good fit.
Absolutely. I've had major problems when I tried to use some Java XML mapping libraries, because they can only process xsd, and not the language you use. So having high-quality xsd definitions is high on my personal wish-list.
the fact that there may be multiple environment to work on the XML files means to me that it's better left off, or maybe provided as a contribution on libvirt.org FTP site, but probably better not integrated, because different users are likely to do things differently. IMHO the key point of libvirt-java is to make sufficient bindings to allow Java developpers to integrate libvirt without pain, while trying to not force them into a specific model (at least not beyond what libvirt itself imposes).
Completely agree.
Also fitting into this model are build makefiles for other environment, I understand that for most Java developpers, configure and make are really foreign tools, so adding ant/Eclipse/... build recipes for the package also makes a lot of sense.
Well, they certainly wouldn't hurt, but I don't see that as a priority. Java-only programmers (end users) won't touch the JNI core parts. They will just install the package, and get on with using it, by adding the jar to their devel enviroment, and perhaps the JNI lib file to the command line. These kind of users don't really care about the java-libvirt build environment. If you want to do something more interesting than renaming the java classes and methods, the you have to hit the JNI bindings, and that code is so ugly, that no-one without some C experience will want to touch it. Having said that, I think that an ant build file would be the most useful, as it can be used directly in all major development enviroments. There is also this maven thing, that seems to be widely used, but I still haven't figured out exactly what that is :-)
What do you think ?
BTW I am working on adding the core bindings for the storage stuff, but don't expect anything soon, as my day job is currently eating all my time.
Okay, cool. BTW libvirt-java review for Fedora seems done now, https://bugzilla.redhat.com/show_bug.cgi?id=453119
so hopefully i should be able to push it to more people real soon now. I also got Solaris portability feedback from John Levon which I need to integrate, there is clearly some work left, but there is no rush :-)
My current plans for java-libvirt are: 1. Add the storage API: It's really mostly just copy-paste-search replace but it still takes some work 2. There are some consistency problems with the naming of classes and methods. I'd like to revisit the java api, and make some changes in names, and maybe class structure 3. There are many places where the C part leaks memory, this should also be audited/ fixed. Number 2 is what worries me, I don't know if it's a good idea to push toFedora, when I know I want to make incompatible API changes soon. (Or you can just say that you won't accept them, but I'm a big fan of clean and consistent APIs, and the current one can be improved) I believe that I will get around to doing 1. and 2. at least in late july/early august, It's about a three day job, I just don't have that three days right now :-( best regards István
Daniel
On Fri, Jul 04, 2008 at 09:23:36PM +0200, T?th Istv?n wrote:
You can see how Daniel Schweger's added functionality is meant to be used in the srtc/testclient/org/libvirt/TestXen.java file.
The way I imagined the java-libvirt architecture is that there is a lower 'core' level, which is basically a function-for function equivalent of the C libvirt functionality, with the bare minimum of object-orientedness thrown in to pass for a proper java library (the current libvirt in CVS)
Yep, I agree the core libvirt-java code should merely be a 1-to-1 mapping of C apis into Java objects.
Plus, there should/can be anotherl API, that exposes the XML files as java objects with get/set functions, etc. (It's in the org.libvirt.schema package in Daniel Schweger's code)
I'm not convinced that this is a good idea as a formal public API - I'd keep it as an internal only impl detail for the higher level API you mention below.
Optionally, there could be higher level API that uses the core and XML api, and provides a really clean java-style object model, but IO haven't given it much thought yet.
As an example - the capabilities XML format provides metadata indicating what values are allowed for the current hypervisor in the domain XML. A high level API could use this information to provide an easier to use API for configuring domains and pre-validating the info.
I think these two or three layers should be clearly demarcated, maybe even shipped as separate packages, becuse anything that layers on more functionaity that what the current cvs provides represents design decisions that are not inherent to libvirt.
I agree that any generated-bean API or higher level API should be part of a separate distributed package. eg a libvirt-java-beans tar.gz to make it clear that its a higher level API. From a practical dev POV it also makes sens because there's no need to couple releases of the higher level API to the underlying libvirt releases / numbering scheme. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Tóth István