[libvirt] RFC: libvirt java bindings based on JNA

[Bryan Kearney]

Thomas Treutner wrote:
> On Tuesday 28 July 2009 14:42:42 Bryan Kearney wrote:
>> Thomas Treutner wrote:
>>> When using it with my tiny test application (which works fine with the
>>> JNI version), it first complains that /etc/pki/CA/cacert.pem can not be
>>> found. As I installed libvirt from source, it's in /usr/local/...,
>>> working fine with JNI. So I did a symlink workaround for now.
>> Where did you see this complaint? Also.. what is your LD_LIBRARY_PATH
>> set to when running this.
> 
> The file not found was cacert.pem, not the *.so - so I don't think 
> LD_LIBRARY_PATH matters here? 
> 
> Anyways, the problem about
> 
> 	conn = new Connect("xen://node02", false);
> 
> was my fault - I forgot wiping an old apt-installed version of libvirt before 
> compiling libvirt-java-jna. It works now, but there seems to be a massive 
> typo somewhere; when I start my small application, it can't 
> find "liblibvirt.so" (sic!) and exits. 

Really.. can you send me the output? What version of jna do you have?


> 
> # find /usr -name "libvirt.so*"                                                             
> /usr/local/lib/libvirt.so.0.6.5
> /usr/local/lib/libvirt.so.0
> /usr/local/lib/libvirt.so
> 
> (ld cache is up to date, checked /etc/ld.so.cache)
> 
> 
> # ln -s /usr/local/lib/libvirt.so /usr/local/lib/liblibvirt.so    
> # ldconfig
> 
> ...and it works! ;-)
> 
>>> When I use the test class (directly on a node where libvirtd is running,
>>> or remote, it doesn't matter), connections to the test driver are
>>> refused, although some test information seems to be gathered, and
>>> connecting with virsh works perfectly:
>> Acutally.. this is bad output. I bet I left the call with the
>> defaultAuth in there. Can you verify that there are 2 open calls in the
>> code I sent?
> 
> This here?
> 
> ...
>  //For testing the authentication
>  ConnectAuth defaultAuth = new ConnectAuthDefault();
> 
> try{
> conn = new Connect("test+tcp://localhost/default", defaultAuth, 0);
> ....
> 

Yes.. this was causing hte failure.. if you comment this out (I am still 
debugging this) you should see it run with no failures.

-- bk