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

[Florian Forster]

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>

On Thu, Feb 19, 2009 at 09:31:44AM -0800, Doug MacEachern wrote:
> A couple of these: java.c:1491: warning: dereferencing type-punned
> pointer will break strict-aliasing rules

argh, I hate that stupid warning! Especially when casting a `char **' to
a `const char * const *'..

> 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..

> 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.

Yeah, meta-meta is geeky-square! :)

> >  * 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..

> 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?

> >  * 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..

> >  * 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 ;)..

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090219/304f29d3/attachment.pgp