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 VFSLogFilePatternReceiver preserved of course - it's turned out to be a very useful Receiver (parse mostly-arbitrary log formats, even remote/ssh). Happy to help I just never have much time. Scott On 1/16/22, Robert Middleton <rmiddle...@apache.org> wrote: > 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-extras > * Add in log4j2 dependencies for logging > * Create a generic Chainsaw log event that is used to pass log events > around internally > * Rework the receivers framework to use ServiceLoader instead of some > home-grown system > > If people are willing to take a look at what I've done so far, the > (very rough still) branch is here: > https://github.com/rm5248/logging-chainsaw/tree/remove-log4j1 > > There are still a number of bugs in it still, since there's a fair > amount of invasive surgery. If you want to test, you'll need to do > the following: > 1. Remove your ~/.chainsaw directory(this may or may not be needed; it > doesn't seem to like to load old settings at the moment) > 2. Start chainsaw > 3. Open the 'receivers' panel(icon that looks like a satellite dish) > 4. Create a new JSON receiver. There's only one option, so you can click > 'ok' > 5. Run log4j2 with a configuration file similar to the following: > > ?xml version="1.0" encoding="UTF-8"?> > <Configuration status="WARN"> > <Appenders> > <Console name="Console" target="SYSTEM_OUT"> > <PatternLayout pattern="LOG4J2 %d{HH:mm:ss.SSS} [%t] %-5level > %logger{36} - %msg%n"/> > </Console> > <Socket name="socket" host="localhost" port="4449"> > <JsonTemplateLayout></JsonTemplateLayout> > </Socket> > </Appenders> > <Loggers> > <Root level="trace"> > <AppenderRef ref="Console"/> > <AppenderRef ref="socket"/> > </Root> > </Loggers> > </Configuration> > > You should then see log messages showing up in a new tab. > > -Robert Middleton > > On Tue, Dec 28, 2021 at 6:32 AM Volkan Yazıcı <vol...@yazi.ci> wrote: >> >> +1 for implementation-agnostic custom DTO tailored for Chainsaw. >> >> On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker <boa...@gmail.com> 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 >> > >> > > On Dec 26, 2021, at 15:50, Ralph Goers <ralph.go...@dslextreme.com> >> > wrote: >> > > >> > > 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 >> > >> <rmiddle...@apache.org> >> > wrote: >> > >> >> > >> 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 will then show the log messages. >> > >> >> > >> There are also a handful of classes from the log4j1 extras package >> > >> that are used as well, such as Rule. >> > >> >> > >> It seems to me that the proper way to do this then is to: >> > >> * Copy any of the log4j1 extras classes we need into Chainsaw >> > >> * Define an internal representation of log messages so that we don't >> > >> depend on the log4j1 LoggingEvent class(perhaps a modified version >> > >> of >> > >> the log4j1 LoggingEvent) >> > >> * Refactor the code so that when a log event comes in, we simply >> > >> push >> > >> it to whatever tab we want to see it on, instead of indirectly via >> > >> log4j1. >> > >> * Create a custom Appender for log4j2 so that we can still see >> > >> internal Chainsaw messages within Chainsaw, and convert internal log >> > >> messages to log4j2. >> > >> >> > >> Thoughts? >> > >> >> > >> -Robert Middleton >> > >> >> > > >> > >> > >
