You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Robert Middleton <rm...@apache.org> on 2022/02/21 23:01:52 UTC
Re: [Chainsaw] Removal of Log4j1
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 <rm...@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 <sc...@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 <rm...@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ı <vo...@yazi.ci> wrote:
> > >>
> > >> +1 for implementation-agnostic custom DTO tailored for Chainsaw.
> > >>
> > >> On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker <bo...@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.goers@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
> > >> > >> <rm...@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
> > >> > >>
> > >> > >
> > >> >
> > >> >
> > >
>
Re: [Chainsaw] Removal of Log4j1
Posted by Robert Middleton <rm...@apache.org>.
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 <sc...@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 <rm...@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 <rm...@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 <sc...@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 <rm...@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ı <vo...@yazi.ci>
> wrote:
> >> > >>
> >> > >> +1 for implementation-agnostic custom DTO tailored for Chainsaw.
> >> > >>
> >> > >> On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker <bo...@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.goers@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
> >> > >> > >> <rm...@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
> >> > >> > >>
> >> > >> > >
> >> > >> >
> >> > >> >
> >> > >
> >>
> >
>
Re: [Chainsaw] Removal of Log4j1
Posted by Scott Deboy <sc...@gmail.com>.
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 <rm...@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 <rm...@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 <sc...@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 <rm...@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ı <vo...@yazi.ci> wrote:
>> > >>
>> > >> +1 for implementation-agnostic custom DTO tailored for Chainsaw.
>> > >>
>> > >> On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker <bo...@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.goers@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
>> > >> > >> <rm...@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
>> > >> > >>
>> > >> > >
>> > >> >
>> > >> >
>> > >
>>
>