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

[Doug MacEachern]

On Feb 19, 2009, at 12:16 PM, Florian Forster wrote:

> Hi Doug,
>
> the interesting bit of information up front, where hopefully more
> people will read it: I try to keep documentation up to date when I
> change stuff. You can usually find the current status by reading the
> collectd-java(5) manpage, which I have put here for your convenience:
>   <http://verplant.org/temp/collectd-java.html>
>

ok, great.
>
>> And I hardcoded configure.in to the linux include and lib paths.
>
> I'm a bit puzzled how that is _supposed_ to work. Especially with that
> `jni_md.h' in a OS-dependent path and `libjvm.so' in an architecture
> dependent path.. Is there such a thing as `libjni-config' or  
> something?
>
> What might work is:
>   $ JAVA_ROOT='/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64'
>   $ ./configure JAVA_CPPFLAGS="-I$JAVA_ROOT/include -I$JAVA_ROOT/ 
> include/linux" \
>       JAVA_LDFLAGS="-L$JAVA_ROOT/jre/lib/amd64/server -Wl,-rpath - 
> Wl,$JAVA_ROOT/jre/lib/amd64/server/"
>
> Intuitive, isn't it? But other than recursively searching some given
> root directory for the appropriate `jni.h', `jni_md.h' and  
> `libjvm.so' I
> can't think of an automatic way to figure this out without the help of
> some `*-config' script..
>

There's no libjni-config like script that I'm aware of, so yes I  
think some config scripting would be required.  The layout may also  
differ between vendor impls of the JVM such as IBM, BEA, etc.  In the  
ant based build for the sigar java bindings we have a conditional for  
each os to find jni_md.h.  I've only dealt with libjvm on windows.   
We use the Java Service Wrapper (http://wrapper.tanukisoftware.org/),  
just checked to see if they might have a util but found:
ls -l wrapper_3.3.2_src/src/c/Makefile-* | wc -l
29

I can at least offer to help test, we use the hudson build system to  
build sigar on several dozen OS+arch combos and could add builds for  
collectd.

>
>>>  * 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.
>
> I've already moved the new OConfigValue and OConfigItem classes along
> with the CollectdAPI helper class into that namespace. I didn't  
> want to
> simply move DataSource and ValueList to there, too, without hearing  
> from
> you first. If at all possible, I'd like to avoid differences (in  
> classes
> of the same name) between jcollectd and the Java plugin..
>

I'm all for re-use and avoiding any duplication!

>> And at some point maybe we can just fold all of jcollectd into
>> bindings/java?
>
> I guess you're the judge on this - I don't know enough about Java  
> to say
> for sure which solution is best..
>
> In my perfect little dream world, we'd build everything that's below
> bindings/java/ into some `collectd-java.jar' or `collectd- 
> bindings.jar'
> and this file can be used like jcollectd and by the Java plugin. Is  
> that
> possible or even desirable?
>

Certainly possible.  I think just `collectd.jar' would be nice,  
there's a small number of class should it should stay small and we  
can use it in both places.  If I make any changes to jcollectd in the  
next few weeks it'd likely be in the mx package, so feel free to hack  
away and re-org, I don't think we'll diverge too much.  And we can  
revisit how-to best fold in the rest later.

>>>  * 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.
>
> In fact, I've already done this. The classes `OConfigValue' and
> `OConfigItem' are an exact copy of their C counterparts,
> `oconfig_value_t' and `oconfig_item_t'. Maybe you could take a look at
> `OConfigValue': I'm missing `unions's in Java, therefore that class
> doesn't look ``nice'', if you ask me..
>

Excellent, I will take a look and try it out soon.

>>>  * 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 class MyPlugin implements CollectdReadPlugin {
>> [...]
>>
>> Collectd.register_read_plugin(new MyPlugin());
>
> So what'd be the advantage of doing it like this? Due to the  
> interface,
> the name / signature of the called functions is fixed anyway,  
> right? We
> could still provide interfaces, so the compiler can help keep out bugs
> (I'm a big fan of interfaces ;)..
>

Right, no need to use an interface but there are some nice Java  
features such as java.lang.reflect.Proxy that require interfaces.  I  
tend to use abstract classes rather than interfaces myself.  There  
are no `function-pointers' in Java, at least not the way you're used  
in C or something like a Perl CV.  You just need to use an Object for  
callbacks.. so I think the only advantage I'd see to having  
`plugin_register_*' in Java would be for plugins to construct the  
objects themselves should they need more context than you might get  
from env->NewObject.  And perhaps having the callback registration  
driven by the code rather than the config.  I'll let you know if I  
have more thoughts once I get to play with it more :)