Hi all,
The `log4j-flume-ng` module _de facto_ contains 3 different appenders:
* an Avro appender, that only depends on Avro and Avro IPC. Since it
only communicates with Flume via network, it doesn't need to even
depend on Flume, it just needs to use the same protocol.
* a Persistent appender, w
I support the idea of removing `log4j-flume-ng` from `main` and figuring
out a resolution later. I think it is too early to decide on how to further
proceed with `log4j-flume-ng`; moving to a separate repository, merging it
back to `main`, etc. The important thing is, we can always add it back to
`
Hi,
I'd like to follow Ralph's lead on Flune related topics.
Gary
On Thu, Aug 29, 2024, 8:12 AM Piotr P. Karwasz
wrote:
> Hi all,
>
> The `log4j-flume-ng` module _de facto_ contains 3 different appenders:
>
> * an Avro appender, that only depends on Avro and Avro IPC. Since it
> only communica
I’d be ok with splitting it out.
> On Aug 29, 2024, at 07:12, Piotr P. Karwasz wrote:
>
> Hi all,
>
> The `log4j-flume-ng` module _de facto_ contains 3 different appenders:
>
> * an Avro appender, that only depends on Avro and Avro IPC. Since it
> only communicates with Flume via network, it d
My only concern for splitting it out is the same one I have for all of our
modules, whether they reside in the same repo as Log4j or not. That is, they
all need to be tested against the latest versions of Log4j.
In the case of the Flume appender unless something specifically is being done
to i
Hi Ralph,
On Thu, 29 Aug 2024 at 23:32, Ralph Goers wrote:
> So I will say I am fine with moving it to its own module. Can it be moved
> while keeping the 2.x and main branches?
Sure, I created a `logging-log4j-flume` repository and I'll move both
branches there preserving the commit history.
