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

[Sebastian Harl]

Hi,

I'm short of time, so here are just two quick comments ... ;-)

On Thu, Feb 19, 2009 at 09:31:44AM -0800, Doug MacEachern wrote:
> On Feb 18, 2009, at 6:34 AM, Florian Forster wrote:
> 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.

That sounds cool. However, as far as I know, Ruby hardly supports any
multi-threaded access to an interpreter. Python seems to allow that but
it uses a "big interpreter lock" to serialize basically anything but IO,
so we might run into quite a few problems in regard to deadlock
prevention. I'm not sure about other interpreted languages, but I'd
expect problems with all of them at first ;-/ (Perl sucks as hell in
that respect - that caused me quite some pain.) Do you happen to know if
the J* implementations of those languages handle multi-threading
specifically in some way?

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

Ack! Having all configuration in one place and using the same syntax
would be a good thing imho.

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

On Thu, Feb 19, 2009 at 05:27:45PM -0800, Doug MacEachern wrote:
> 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..

JFTR: In the perl plugin, I cannot use CVs either, because Perl does not
allow to share function pointers between threads. I decided to use
function names instead. That was easy to handle, at least made a
_little_ sense to me and, afaik, did not introduce a lot of overhead. If
that makes sense in Java as well, you might want to consider to go that
way as well - then we'd be more consistent. Of course, if that makes
only little sense or would introduce a non-intuitive (for Java
programmers) interface, then don't do it ;-)

(I just got the idea to introduce an object-oriented interface to
collectd in Perl as well ... possibly in addition to the currently
existing interface ... ;-))

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

Imho, the biggest advantage of having `plugin_register_*' is to be able
to _explicitly_ state (in the code) what you want to do. I'm not a big
fan of letting things happen magically.

Well, that's more than two comments now ... ;-)

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- 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/20090220/7ca16ca0/attachment-0001.pgp