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 > > >> > > > > > > >
