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 2021/12/26 21:13:59 UTC
[Chainsaw] Removal of Log4j1
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
>> > >> > >>
>> > >> > >
>> > >> >
>> > >> >
>> > >
>>
>
Re: [Chainsaw] Removal of Log4j1
Posted by Robert Middleton <rm...@apache.org>.
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>.
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 <ra...@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>.
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 <ra...@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'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 <ra...@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 Volkan Yazıcı <vo...@yazi.ci>.
+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 <ra...@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 Matt Sicker <bo...@gmail.com>.
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 <ra...@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 Ralph Goers <ra...@dslextreme.com>.
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
>