This is a great post Matt!
Fluentbit, Fluentd, Logstash, and Filebeat are the main tools used for log
forwarding. While they all have some amount of plugability none of the are as
flexible as Flume. In addition, as I have mentioned before, none of them
provide guaranteed delivery so I would
One of the main reasons why I supported Flume joining this PMC was that I
noticed it has significant overlap with projects in the observability space
despite not being advertised as such. For example, the project FluentBit is
extremely similar to Flume, but its main purpose is for collecting,
Thank you Scott,
It is very encouraging you are joining this effort! Now I feel more confident
we can make a new release!
I am doing my best to learn more about Chainsaw and contribute further!
On Wed, Nov 29, 2023, at 20:13, Scott Deboy wrote:
> I'll go through the UI and re-add small features
I'll go through the UI and re-add small features that I think are
critical but were lost in the log4j1-jettison effort.
I'll follow-up in a new thread.
Scott
On 11/28/23, Scott Deboy wrote:
> I've fixed the logger tree split pane UI (left artifacts when you
> drag), and I've added
There’s a JUnit annotation `@Issue` or something like that (Spock has a similar
annotation) which you can use for linking to an issue. Otherwise, adding `@Tag`
annotations allows for arbitrary tags (of which we use several already such as
“functional” and “sleepy”).
> On Nov 28, 2023, at 5:55
I’m good with a beta release to come soon. I’m still working on a branch to fix
up the remaining SPI updates to avoid guessing at ClassLoaders, but that isn’t
required for a beta release. As for the branches, if 2.x was made into 3.0,
then main would be 4.0, and where would that leave us? Back
Small changes to that:
* Should move the XML configuration format to its own module, too, for the
java.xml dependency
* Should remove the Jackson JSON configuration format as we have a
dependency-free JSON format in core (the YAML format support is based on the
Jackson JSON support, so this
I can tell you that some people I work with would use property files for
everything under the sun if they could...
Gary
On Wed, Nov 29, 2023, 9:29 AM Ralph Goers
wrote:
> I agree with this. IMO the only configuration syntaxes we should support
> are those we can implement with no dependencies.
FWIw, the situation you describe isn’t really any different than it is with
Maven. If I declare an optional dependency in a component it will not be
automatically included. A user has to add it to their pom.xml as a required
dependency for it to be included. That is really no different than a
I agree with this. IMO the only configuration syntaxes we should support are
those we can implement with no dependencies. At the moment that is JSON and
Properties (Ugh!). I would love to deprecate properties but I know that is a
non-starter since we didn’t support them for years and were
I think the overall goal should be to have no optional dependencies, no
surprises. I personally hope to never force YAML on anyone.
Gary
On Wed, Nov 29, 2023, 6:51 AM Piotr P. Karwasz
wrote:
> Hi all,
>
> I have been using a modularized sandbox project to test Log4j and
> optional dependencies
Hi all,
I have been using a modularized sandbox project to test Log4j and
optional dependencies are a nightmare.
Small example: if I use Log4j API in my project and I add:
requires org.apache.logging.log4j;
then when I run the app, the JVM will automatically add `log4j-api` to
the boot layer.
12 matches
Mail list logo
