Hi Vincent,

I'm apologize for not contacting with you to discuss this question (it was my plan, but I run out of time and unfortunately I forgot it).

As you pointed out: in incubator there is a non-java based Kafka driver.
My plan is to keep it in the incubator and give the choice to the users.
If someone needs a non-java Kafka destination then we can say: we have such a driver in the incubator.
On the other hand, if someone wants to use a Kafka dst which is built around the official Kafka java client library,
then she/he can use it.
(Kafka was a really good candidate for implement it on the basis of the new Java language binding.)

L.

On Mon, Aug 17, 2015 at 5:11 PM, Vincent Bernat <bernat@luffy.cx> wrote:
 ❦ 17 août 2015 16:45 +0200, "Budai, László" <laszlo.budai@balabit.com> :

> ElastiSearch, Kafka and HDFS destination drivers are implemented by
> using the 'official' Java client libraries and syslog-ng provides a
> way to set their own, native configuration file. Log messages
> generated by the client Java libraries are redirected to syslog-ng via
> our own Log4JAppender which means that those logs are available as
> internal syslog-ng messages.
>
> * ElasticSearch
> * Kafka
> * Hadoop/HDFS
> * HTTP

That's a great addition but there is a working Kafka driver not
depending on JVM waiting in syslog-ng incubator. This JVM-based Kafka
driver comes a bit as a surprise. What does it mean for the Kafka driver
currently in the incubator?
--
If one cannot enjoy reading a book over and over again, there is no use
in reading it at all.
                -- Oscar Wilde