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