[collectd] (Generic) Java plugin available for development/testing.

[Doug MacEachern]

On Feb 18, 2009, at 6:34 AM, Florian Forster wrote:
...
>
> The code is available in the `ff/java' branch from the normal collectd
> Git repository.
>

Very cool Florian!  I needed two changes to build...
A couple of these: java.c:1491: warning: dereferencing type-punned  
pointer will break strict-aliasing rules

And I hardcoded configure.in to the linux include and lib paths.

% find /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64 -name jni_md.h
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/include/linux/jni_md.h

% find /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64 -name libjvm.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/ 
libjvm.so

I haven't tried it yet, but i think it'd be most interesting to  
integrate with JRuby, JPython, etc., then we can have in-process  
plugins in ruby and python.  There's plenty of other nice scripting  
languages that run on the jvm, Groovy, Ioke, etc.

> As sad above, any feedback is highly welcome. Here are some of the
> questions I currently have in mind:
>
>   * Would it make sense to move `CollectdAPI' and `ValueList' and
>     `DataSource' to `org.collectd.api' or something like that?
>

Glad you were able to use some of the jcollectd classes.  I think the  
org.collectd.api package would make sense.  And at some point maybe  
we can just fold all of jcollectd into bindings/java?

>   * I was going to write a Java representation of the `config_item_t'
>     data structure, so Java plugins can be configured more or less  
> like
>     C plugins. Does that make sense or is there some magic and  
> standard-
>     ized way to configure Java programs/components?
>

As with most 'standards' there are many to choose from ;)  I think  
it'd be best to have it the collectd way, then we can implement  
classes on top that can read from other config file formats.

>   * Would it be better to implement the `plugin_register_*'  
> interface in
>     Java, too? As far as I know function-pointers are a bit tricky in
>     Java, right?


Yeah, the convention would be something like:

public interface CollectdReadPlugin {
      public int read();
}

public class MyPlugin implements CollectdReadPlugin {
     public int read() {
         ... plugin_dispatch_values(vl);
     }
}

Collectd.register_read_plugin(new MyPlugin());



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-avoid-warning-dereferencing-type-punned-pointer-wil.patch
Type: application/octet-stream
Size: 2153 bytes
Desc: not available
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090219/c676d5ee/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flags.patch
Type: application/octet-stream
Size: 676 bytes
Desc: not available
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090219/c676d5ee/attachment-0001.obj