collectd.conf(5), collectd-java(5): Updated the documentation for the Java plugin.

[collectd.git] / src / collectd.conf.pod

diff --git a/src/collectd.conf.pod b/src/collectd.conf.pod
index e894628..1ab4360 100644 (file)
--- a/src/collectd.conf.pod
+++ b/src/collectd.conf.pod
@@ -1101,7 +1101,7 @@ Synopsis:
    </Plugin>
  </Plugin>
 
-Available config options:
+Available configuration options:
 
 =over 4
 
@@ -1111,6 +1111,10 @@ Argument that is to be passed to the I<Java Virtual Machine> (JVM). This works
 exactly the way the arguments to the I<java> binary on the command line work.
 Execute C<javaE<nbsp>--help> for details.
 
+Please note that B<all> these options must appear B<before> (i.E<nbsp>e. above)
+any other options! When another option is found, the JVM will be started and
+later options will have to be ignored!
+
 =item B<LoadPlugin> I<JavaClass>
 
 Instantiates a new I<JavaClass> object. The constructor of this object very
@@ -1118,10 +1122,20 @@ likely then registers one or more callback methods with the server.
 
 See L<collectd-java(5)> for details.
 
-=item B<Plugin> I<JavaClass>
+When the first such option is found, the virtual machine (JVM) is created. This
+means that all B<JVMArg> options must appear before (i.E<nbsp>e. above) all
+B<LoadPlugin> options!
+
+=item B<Plugin> I<Name>
+
+The entire block is passed to the Java plugin as an
+I<org.collectd.api.OConfigItem> object.
 
-The entrie block is passed to the Java plugin as an
-I<org.collectd.api.OConfigItem> object. See L<collectd-java(5)/"config callback">.
+For this to work, the plugin has to register a configuration callback first,
+see L<collectd-java(5)/"config callback">. This means, that the B<Plugin> block
+must appear after the appropriate B<LoadPlugin> block. Also note, that I<Name>
+depends on the (Java) plugin registering the callback and is completely
+independent from the I<JavaClass> argument passed to B<LoadPlugin>.
 
 =back