I just merged it in a few hours ago, but if you are able to check it out
that would be nice too! It is still a little buggy at the moment, so some
changes still need to be done.
I've started updating at least some of the documentation here:
https://github.com/apache/logging-chainsaw/tree/document
I'll check out your branch - there are a ton of features, I'll put
some documentation together on what exists.
Advertiser support is already there now btw.
Scott
On 2/21/22, Robert Middleton wrote:
> I've finished removing log4j1 from Chainsaw. If anybody would like to take
> a look, it is in
I've finished removing log4j1 from Chainsaw. If anybody would like to take
a look, it is in a PR here:
https://github.com/apache/logging-chainsaw/pull/11
The next steps probably are:
* Make sure dependencies are up to date
* Create a better way of documenting how receivers work other than just
th
Thanks for the input. In that case I will certainly make sure that we
do keep the VFSLogFilePatternReceiver.
One thing that would be helpful if you have time Scott would be a
manual on how to use Chainsaw and the features that it has. I
understand it enough now, but for people first trying to us
Looks great!
It's a lot of work for sure - lots more to do to fully remove log4j1 -
custom level support (java.util.logging and Android for example),
support for UI-based interactions for some receivers(activateOptions),
and the loggerRepository extension pieces.
I definitely want to see VFSLogFi
I've been working on this for a little bit now, and I do have
something that mostly seems to work. This has been made somewhat more
difficult by the very tight coupling that Chainsaw has with log4j1 and
its plugin framework. At this point, I've done the following:
* Remove dependency on log4j1-e
+1 for implementation-agnostic custom DTO tailored for Chainsaw.
On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker wrote:
> I agree on the generic approach. While there’s a LogEvent interface in
> log4j2, it would probably make sense for Chainsaw to define its own DTOs
> and such.
> --
> Matt Sicker
>
I agree on the generic approach. While there’s a LogEvent interface in log4j2,
it would probably make sense for Chainsaw to define its own DTOs and such.
--
Matt Sicker
> On Dec 26, 2021, at 15:50, Ralph Goers wrote:
>
> Scott has been sort of maintaining Chainsaw on his own for years. I am sur
Scott has been sort of maintaining Chainsaw on his own for years. I am sure he
would love new energy in the project.
I think isolating it from any logging framework implementation would be a good
thing.
Ralph
> On Dec 26, 2021, at 2:13 PM, Robert Middleton wrote:
>
> I've been looking into
I've been looking into Chainsaw to remove Log4j1, since that is rather
obsolete at this point. Unfortunately, Chainsaw is closely tied to
Log4j1, as it seems that what happens is when it receives events from
a source, it sends the messages to a custom LoggerRepository with a
custom appender that w
10 matches
Mail list logo