On 09/21/2013 09:15 AM, Hugo Trippaers wrote:
Hey Wido,
Did they publish the updated jar with the same version number? If that is the
case maven will not take care of it as by definition release artefacts will be
cached indefinitely and never be replaced. Only snapshot dependencies will be
updated.
They didn't publish a new JAR yet. They want some feedback on 0.5.0
first if it technically works, if so, they will release 0.5.1 which is
Java 6 compatible.
Wido
Cheers,
HUgo
On Sep 21, 2013, at 3:03 PM, Wido den Hollander <w...@widodh.nl> wrote:
On 09/17/2013 08:35 PM, Mike Tutkowski wrote:
I'm not familiar with how we package these binding classes in CloudStack.
Is there a new JAR I need to download or source code?
Sorry, forgot this one! Nothing to do on your side. Maven will take care of
this.
The RPM and DEB packaging will automatically include these bindings.
Wido
Thanks!
On Mon, Sep 16, 2013 at 2:19 PM, Wido den Hollander <w...@widodh.nl> wrote:
On 09/16/2013 07:46 PM, Min Chen wrote:
I got the following test failure in building master:
Running com.cloud.hypervisor.kvm.**resource.**
LibvirtComputingResourceTest
Tests run: 3, Failures: 0, Errors: 2, Skipped: 1, Time elapsed: 0.059 sec
<<< FAILURE!
testCreateVMFromSpecLegacy(**com.cloud.hypervisor.kvm.**
resource.LibvirtComputi
ngResourceTest) Time elapsed: 0.018 sec <<< ERROR!
java.lang.**UnsupportedClassVersionError: org/libvirt/LibvirtException :
Unsupported major.minor version 51.0
at java.lang.ClassLoader.**defineClass1(Native Method)
at java.lang.ClassLoader.**defineClassCond(ClassLoader.**
java:631)
at java.lang.ClassLoader.**defineClass(ClassLoader.java:**615)
at java.security.**SecureClassLoader.defineClass(**
SecureClassLoader.java:141)
at java.net.URLClassLoader.**defineClass(URLClassLoader.**
java:283)
at java.net.URLClassLoader.**access$000(URLClassLoader.**java:58)
at java.net.URLClassLoader$1.run(**URLClassLoader.java:197)
at java.security.**AccessController.doPrivileged(**Native Method)
at java.net.URLClassLoader.**findClass(URLClassLoader.java:**190)
at java.lang.ClassLoader.**loadClass(ClassLoader.java:**306)
at sun.misc.Launcher$**AppClassLoader.loadClass(**
Launcher.java:301)
at java.lang.ClassLoader.**loadClass(ClassLoader.java:**247)
at
com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResourceTest.**
testCreateVM
FromSpecLegacy(**LibvirtComputingResourceTest.**java:64)
Wido, is this related to this libvirt change?
I think so. I'll test this tomorrow, but I think the RedHat guys build the
bindings with Java 7 since they all work on a recent Fedora version.
Wido
Thanks
-min
On 9/16/13 4:28 AM, "Wido den Hollander" <w...@widodh.nl> wrote:
On 09/16/2013 12:51 PM, Wei ZHOU wrote:
Thanks Wido.
Do you know the minimal requirement of libvirt if we use libvirt-java
0.5.0
?
There shouldn't be a difference in the required libvirt version. I
implemented a couple of methods in the bindings which were already in
libvirt for a long time, but the bindings was just missing them.
Wido
2013/9/16 Wido den Hollander <w...@widodh.nl>
Hi,
I worked with the RedHat guys last week to get libvirt-java 0.5.0
released
which has some nice new features for us:
- Supports different XML on destination host during migration
- Supports resizing volumes
- Supports more snapshot functionalities
I took the liberty to depend on 0.5.0 in master and also merge in the
code
for the VNC listen, we now no longer listen on 0.0.0.0 for VNC, which
was a
security issue imho.
The reason I'm bringing this to the list is that we can simplify some
code
around resizing volumes and snapshotting where we currently have some
nasty
scripts to do the work.
See my commits in libvirt-java:
http://www.libvirt.org/git/?p=****<http://www.libvirt.org/git/?p=**>
libvirt-java.git;a=summary<htt**p://www.libvirt.org/git/?p=**
libvirt-java.gi <http://www.libvirt.org/git/?p=libvirt-java.gi>
t;a=summary>
So keep in mind libvirt-java has some new features!
Wido
