Re: [Chainsaw] Removal of Log4j1

2022-03-04 Thread Robert Middleton
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

Re: [Chainsaw] Removal of Log4j1

2022-03-04 Thread Scott Deboy
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

Re: [Chainsaw] Removal of Log4j1

2022-02-21 Thread Robert Middleton
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

Re: [Chainsaw] Removal of Log4j1

2022-01-17 Thread Robert Middleton
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

Re: [Chainsaw] Removal of Log4j1

2022-01-16 Thread Scott Deboy
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

Re: [Chainsaw] Removal of Log4j1

2022-01-16 Thread Robert Middleton
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

Re: [Chainsaw] Removal of Log4j1

2021-12-28 Thread Volkan Yazıcı
+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 >

Re: [Chainsaw] Removal of Log4j1

2021-12-27 Thread 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

Re: [Chainsaw] Removal of Log4j1

2021-12-26 Thread Ralph Goers
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

[Chainsaw] Removal of Log4j1

2021-12-26 Thread Robert Middleton
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