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/documentation-updates The newest documentation is up on the staging site too: https://logging.staged.apache.org/chainsaw/2.2.0/quicktour.html -Robert Middleton On Fri, Mar 4, 2022 at 6:30 PM Scott Deboy <scott.de...@gmail.com> wrote: > 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 <rmiddle...@apache.org> wrote: > > 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 > > throwing javadoc at the user > > * Create a full tutorial and documentation for chainsaw, since the > > documentation is pretty non-existent now > > * Integrate with the Advertisers that log4j2 has so you can easily > connect > > to an application using log4j2 > > * Look at JDeploy that Matt linked to and determine if that would be a > good > > way to distribute chainsaw > > > > -Robert Middleton > > > > On Mon, Jan 17, 2022 at 2:02 PM Robert Middleton <rmiddle...@apache.org> > > wrote: > > > >> 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 use it there > >> isn't really any good documentation. > >> > >> -Robert Middleton > >> > >> On Mon, Jan 17, 2022 at 1:17 AM Scott Deboy <scott.de...@gmail.com> > >> wrote: > >> > > >> > 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 > >> > >> > >> > >> > >> > > > >> > >> > > >> > >> > > >> > > > >> > > >
