Re: Planning out what we can do to get Chainsaw back in the game

[Scott Deboy]

Awesome!  Happy to help here where I can, although I haven't worked in
Java in forever.

Chainsaw is really five parts:

 - Receivers which grab the data from whatever source
 - The 'route events to tabs' mechanism
 - Table/event rendering, including search/filter/colorization and
time deltas between events
 - A hierarchical tree of loggers, which is a quick way to perform
logger-level filtering
 - An expression syntax used by search/filter/colorization

The UI has a TON of features which have been added over the years.

The receivers are functional but not great (see the xmlreceiver for
example).  The most useful receiver is VFSLogFilePatternReceiver IMO.
Would be great to modernize things a bit, adding support for logstash
for example would be handy.

The sorting is wonky and slow, especially if sorting times (!)

The logic supporting the color/search match bar (to the right of the
table) as well as time delta bar (to the left of the table) is
overkill and awkward.  The color bar is very useful - you can see
color and search matches in the entire file at a glance.  The time
delta bar, not so much.

Chainsaw' support for positive and negative filters, combined with
colorizing, search and event annotation combine to give you a pretty
powerful set of tools for log analysis.  It'd take a long time to
recreate what's there in another language.

Scott

On 10/14/17, Matt Sicker  wrote:
> I'm looking at the infra stuff right now. Found this: <
> https://issues.apache.org/jira/browse/INFRA-8439>. So it appears we may
> already have the webstart code signing thing handled. More info here: <
> https://blogs.apache.org/infra/entry/code_signing_service_now_available>.
>
> On 14 October 2017 at 13:12, Gary Gregory  wrote:
>
>> I would really stay away from Java 9 at this point. There is too much
>> incompatible tooling out there at this point. I can't even run most apps
>> out of the box I have laying around on Java 9 without breakage.
>>
>> Gary
>>
>> On Sat, Oct 14, 2017 at 12:09 PM, Matt Sicker  wrote:
>>
>> > I forgot to mention my current difficulty in the release process are
>> broken
>> > tests. I just noticed that my default Java version on this computer is
>> > actually 9, not 8, so that could be related. Any guidance from anyone
>> who's
>> > successfully built this before would be great.
>> >
>> > On 14 October 2017 at 13:01, Matt Sicker  wrote:
>> >
>> > > First off, for some reason, there are two repositories:
>> > >
>> > > https://github.com/apache/chainsaw
>> > > https://github.com/apache/logging-chainsaw
>> > >
>> > > The second one appears to be up to date. Not sure what to do about
>> > > the
>> > > first one as it seems to be a relic of when Chainsaw was in SVN.
>> > >
>> > > Next, bug tracking. The pom says its bugs are tracked in Bugzilla. It
>> was
>> > > tracked as a component of Log4j 1. See this: > > > bugzilla/buglist.cgi?bug_status=__open__&component=
>> > > chainsaw&product=Log4j%20-%20Now%20in%20Jira>. I believe it would be
>> > > useful to switch over to JIRA like we're using for the rest of the
>> > logging
>> > > projects. Perhaps we can ask infra for some sort of issue transfer if
>> > > possible.
>> > >
>> > > Another issue: the Java source version is set to 1.4. That means it
>> > > doesn't even compile using Java 8 due to 1.6 being the oldest source
>> > > version usable. That also means that this project hasn't been updated
>> to
>> > > use generics let alone anything else from the past 13 years (Java 5
>> > > was
>> > > released in 2004 back when I was learning how to program in the first
>> > > place!). As such, incrementing the base Java version to 1.6 would be
>> > > a
>> > > minimum change, and I think if we increased to Java 8 or 9 after a
>> > release,
>> > > that would give us a nice opportunity to do some mechanical
>> refactorings
>> > > and such which can sometimes be fun.
>> > >
>> > > Really, though, the choice of Java version or JVM language in general
>> for
>> > > a modernized version should be determined by whoever is interested in
>> > > helping clean everything up and move forward. In that case, since I
>> feel
>> > a
>> > > bit interested here, I'd propose going with either Java 9 or Scala
>> > > 2.12
>> > > (Scala provides a neat Swing API wrapper as well). Kotlin could also
>> be a
>> > > contender here, though I haven't used it much at all yet, so I can't
>> > really
>> > > make a real recommendation there. There's also the option of
>> > > migrating
>> > from
>> > > Swing to JavaFX if there is interest, though I've never really used
>> > JavaFX
>> > > before (but have used Swing).
>> > >
>> > > Then there is the notion of distribution. Since this is a GUI app,
>> > > it's
>> > > not generally as simple as just publishing to Maven Central.
>> > > Naturally,
>> > the
>> > > standard Apache release process of publishing sources and binaries to
>> SVN
>> > > works fine, but there are additional options we can consider:
>> > > * Publish a

Re: Planning out what we can do to get Chainsaw back in the game

[Scott Deboy]

Try out Chainsaw - it's super useful once you get the model.  Under
help, there's info on the expression syntax, and the chainsaw-log tab
(where chainsaw log messages route by default) can be a playground for
working with the colorization/filtering/expressions.

Here's my general flow:

1. Filter at the logger level using the logger tree on the left.
Right-click on the root or at a logger level to explicitly hide or
unhide loggers and their children

2. Build a custom expression to ignore other cruft you don't want to
look at. Click on the ellipses next to 'Ignore' below the logger tree
to define a custom expression you can use to hide additional stuff.

Now that you have your 'base' set of events you want to look at, you
can use the 'Refine focus on' box to define an expression to match
specific events you want to see.
Try: msg ~= receiver

Entering an expression in the 'Find' box will find matches, and you
can move through those matches with  F3/Shift-F3
Try: level >= warn

Expressions can be &&'d and ||'d and paren'd, and you can use most of
the fields like msg, level, logger, or 'exception exists' in java-land
since we try to parse java exceptions into the 'throwable' field.

One last thing: Event annotation.

Click on the 'Marker' field and enter something.  You can bounce
between annotations with F2/Shift F2.

You can bounce between any color rule (search, marker or custom color
expression) using Cmd-N and Cmd-P (mac shortcut at least).

Right click on a row in the table to get to the color expression
screen, where you can order color matching expressions - first match
wins.

Hope that helps - love to hear feedback.

Scott

On 10/14/17, Matt Sicker  wrote:
> On 14 October 2017 at 13:22, Ralph Goers 
> wrote:
>
>> I’ve worked with JavaFX. It is pretty easy. I have zero interest in
>> working with Swing.
>>
>
> Good to know! For Kotlin support, this project looks handy: <
> https://github.com/edvin/tornadofx>. For Scala support, there's this: <
> http://www.scalafx.org/>. The extent of my current JavaFX knowledge is
> basically that I know there are some sort of psuedo-XML files to describe
> the GUI (or you can use the API directly), and that it uses CSS to some
> extent.
>
>
>> I’d prefer to get away from WebStart. I think that may have been what
>> hung
>> up Scott in the first place as he needed a cert. Some of the other
>> technologies for binary deployment make sense to me.
>>
>
> Infra has an official way to sign things for this now, so it might not be
> as bad as back when Scott was trying to get support for it in the first
> place. With Java 9, I think it'll be easier to bundle up .exe/.app files
> for Windows and macOS, and GNU/Linux still has a million ways to package
> things, but there are some maven plugins out there to create some common
> ones (rpm, deb, etc.). There's also Flatpak  for that
> as well. Distributing them from dist.a.o works fine, though distributing in
> app stores generally requires a signing key the same way that webstart
> does.
>
>
>> To be honest, I’ve never run Chainsaw or Lillith. I am not sure how they
>> differ. I am not a big fan of having two projects that do exactly the
>> same
>> thing so I’d like some understanding of what they do and how they differ.
>>
>
> Most of my log viewing happens either via console programs (tail, grep,
> clog, tried out some others that I can't remember) or via shitty web GUIs
> (Kibana, Graylog, Splunk, etc.). If I could find or help build a GUI that
> works better for that, then that'd be great. I'm also not a fan of the
> whole "embed Chrome and call it a native app" movement going on with
> Electron; even Java is lightweight on the desktop in comparison!
>
> --
> Matt Sicker 
>

Re: Planning out what we can do to get Chainsaw back in the game

[Scott Deboy]

Parsing time strings to their numeric values using SimpleDateFormat is
painfully slow - I don't even use it any longer when I'm looking at
1M+ rows in Chainsaw.

Implementation wise I wrote this in the heyday of Logrj1, so
LoggingEvent and a few other features of Log4j1, a number of which
aren't present at all in log4j2, are found throughout the code.

A json receiver would be great!

Me, I've been working on a private cloud IaaS implementation for a few
years now - almost no Java there.

Scott

On 10/14/17, Matt Sicker  wrote:
> On 14 October 2017 at 13:28, Scott Deboy  wrote:
>
>> Awesome!  Happy to help here where I can, although I haven't worked in
>> Java in forever.
>>
>
> Are you using any other JVM languages regularly? Or have you gone down the
> native code route or something?
>
>
>> Chainsaw is really five parts:
>>
>>  - Receivers which grab the data from whatever source
>>
>
> This is the part I'm most interested in improving first. We already have a
> pretty standard JSON layout (and XML and YAML) which now have standard ways
> to parse them in log4j-core's API. As I mentioned as well, supporting some
> binary formats would be useful here, too.
>
>
>> The sorting is wonky and slow, especially if sorting times (!)
>>
>
> We might be able to address this by abusing some big data tech like Apache
> CarbonData or similar columnar formats. Or even just using an embedded
> SQLite or H2 database or similar.
>
>
>> Chainsaw' support for positive and negative filters, combined with
>> colorizing, search and event annotation combine to give you a pretty
>> powerful set of tools for log analysis.  It'd take a long time to
>> recreate what's there in another language.
>>
>
> I suppose this could be an advantage for going with Kotlin since there are
> ways to mechanically convert Java to Kotlin which produces pretty decent
> code most of the time from what I hear. Sticking with a JVM language for
> the project does provide the ability to incrementally migrate to another
> language since they all support linking and compiling Java source files as
> well.
>
> --
> Matt Sicker 
>

Re: Planning out what we can do to get Chainsaw back in the game

[Scott Deboy]

FYI, I think most folks just use pattern layout, which probably makes
VFSLogFilePatternReceiver the most commonly used receiver.  Since it's
VFS, anything accessible over SSH is retrievable and can be
live-tailed.

Also, Chainsaw V2 can pull in logs generated by Log4j2 if you
configure an Advertiser - it uses VFSLogFilePatternReceiver, which
assumes your source can be pulled via one of VFS's supported sources
(file:// or sftp:// are the most common).

I use VFSLogFilePatternReceiver in my cloud configs to remotely tail
logs from multiple hosts and combine those logs into a single view in
Chainsaw.

Scott


On 10/16/17, Matt Sicker  wrote:
> On 16 October 2017 at 14:19, Mikael Ståldal  wrote:
>
>> I think that adding support for Log4j 2's JsonLayout should be top
>> priority when we have figured out how to build, release and distribute
>> it.
>> It should be fairly easy since we can use the new JsonLogEventParser in
>> log4j-core.
>>
>
> Agreed. Moving away from serialized layouts and having first class support
> for any type of safer serialized layout (in this case, the existing json
> layout) should be emphasized.
>
> --
> Matt Sicker 
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Wow that screen shot looks ancient and ugly.  I should pull up
something on the Mac with updated default colors - it looks much
better.

Scott

On 11/10/17, Matt Sicker  wrote:
> Oh, and in case it isn't obvious how to test this, you can extract from
> either the zip or tar.gz files and run the chainsaw script in bin/
> corresponding to your operating system. Note that this crashes when using
> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>
> I built this using Java 1.8.0_111 on macOS 10.12.6.
>
> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>
>> Quick note: using the maven-release-plugin doesn't seem to work in this
>> project. Also, sources and documentation are included in the bin.* files
>> while the standalone.* files are just the jars and startup scripts.
>>
>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>
>>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>>
>>> (Note: I've created release instructions on the new wiki: <
>>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
>>> w+Release+Guide>)
>>>
>>> Artifacts:
>>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>>> svn revision 23048
>>>
>>> Site:
>>> http://musigma.org/chainsaw-site/
>>>
>>> Git:
>>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>>> tag: chainsaw-2.0.0-rc1
>>>
>>> All artifacts have been signed by my PGP key
>>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
>>> KEYS file.
>>>
>>> This vote will be open for at least 72 hours and requires at least 3 +1
>>> votes and more +1 votes than -1 votes.
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> Matt Sicker 
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Would it be possible for me to push an updated screenshot and re-spin?

On 11/10/17, Scott Deboy  wrote:
> Wow that screen shot looks ancient and ugly.  I should pull up
> something on the Mac with updated default colors - it looks much
> better.
>
> Scott
>
> On 11/10/17, Matt Sicker  wrote:
>> Oh, and in case it isn't obvious how to test this, you can extract from
>> either the zip or tar.gz files and run the chainsaw script in bin/
>> corresponding to your operating system. Note that this crashes when using
>> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>>
>> I built this using Java 1.8.0_111 on macOS 10.12.6.
>>
>> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>>
>>> Quick note: using the maven-release-plugin doesn't seem to work in this
>>> project. Also, sources and documentation are included in the bin.* files
>>> while the standalone.* files are just the jars and startup scripts.
>>>
>>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>>
>>>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>>>
>>>> (Note: I've created release instructions on the new wiki: <
>>>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
>>>> w+Release+Guide>)
>>>>
>>>> Artifacts:
>>>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>>>> svn revision 23048
>>>>
>>>> Site:
>>>> http://musigma.org/chainsaw-site/
>>>>
>>>> Git:
>>>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>>>> tag: chainsaw-2.0.0-rc1
>>>>
>>>> All artifacts have been signed by my PGP key
>>>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
>>>> KEYS file.
>>>>
>>>> This vote will be open for at least 72 hours and requires at least 3 +1
>>>> votes and more +1 votes than -1 votes.
>>>>
>>>> --
>>>> Matt Sicker 
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Awesome..I'll commit a new screenshot then.

On 11/10/17, Ralph Goers  wrote:
> The web site doesn’t have to be locked into the release.  An image can be
> updated after the release pretty easily.
>
> Ralph
>
>
>> On Nov 10, 2017, at 1:03 PM, Scott Deboy  wrote:
>>
>> Would it be possible for me to push an updated screenshot and re-spin?
>>
>> On 11/10/17, Scott Deboy  wrote:
>>> Wow that screen shot looks ancient and ugly.  I should pull up
>>> something on the Mac with updated default colors - it looks much
>>> better.
>>>
>>> Scott
>>>
>>> On 11/10/17, Matt Sicker  wrote:
>>>> Oh, and in case it isn't obvious how to test this, you can extract from
>>>> either the zip or tar.gz files and run the chainsaw script in bin/
>>>> corresponding to your operating system. Note that this crashes when
>>>> using
>>>> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>>>>
>>>> I built this using Java 1.8.0_111 on macOS 10.12.6.
>>>>
>>>> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>>>>
>>>>> Quick note: using the maven-release-plugin doesn't seem to work in
>>>>> this
>>>>> project. Also, sources and documentation are included in the bin.*
>>>>> files
>>>>> while the standalone.* files are just the jars and startup scripts.
>>>>>
>>>>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>>>>
>>>>>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>>>>>
>>>>>> (Note: I've created release instructions on the new wiki: <
>>>>>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
>>>>>> w+Release+Guide>)
>>>>>>
>>>>>> Artifacts:
>>>>>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>>>>>> svn revision 23048
>>>>>>
>>>>>> Site:
>>>>>> http://musigma.org/chainsaw-site/
>>>>>>
>>>>>> Git:
>>>>>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>>>>>> tag: chainsaw-2.0.0-rc1
>>>>>>
>>>>>> All artifacts have been signed by my PGP key
>>>>>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the
>>>>>> Logging
>>>>>> KEYS file.
>>>>>>
>>>>>> This vote will be open for at least 72 hours and requires at least 3
>>>>>> +1
>>>>>> votes and more +1 votes than -1 votes.
>>>>>>
>>>>>> --
>>>>>> Matt Sicker 
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker 
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker 
>>>>
>>>
>>
>
>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Updated screenshot.

On 11/10/17, Scott Deboy  wrote:
> Awesome..I'll commit a new screenshot then.
>
> On 11/10/17, Ralph Goers  wrote:
>> The web site doesn’t have to be locked into the release.  An image can be
>> updated after the release pretty easily.
>>
>> Ralph
>>
>>
>>> On Nov 10, 2017, at 1:03 PM, Scott Deboy  wrote:
>>>
>>> Would it be possible for me to push an updated screenshot and re-spin?
>>>
>>> On 11/10/17, Scott Deboy  wrote:
>>>> Wow that screen shot looks ancient and ugly.  I should pull up
>>>> something on the Mac with updated default colors - it looks much
>>>> better.
>>>>
>>>> Scott
>>>>
>>>> On 11/10/17, Matt Sicker  wrote:
>>>>> Oh, and in case it isn't obvious how to test this, you can extract
>>>>> from
>>>>> either the zip or tar.gz files and run the chainsaw script in bin/
>>>>> corresponding to your operating system. Note that this crashes when
>>>>> using
>>>>> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>>>>>
>>>>> I built this using Java 1.8.0_111 on macOS 10.12.6.
>>>>>
>>>>> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>>>>>
>>>>>> Quick note: using the maven-release-plugin doesn't seem to work in
>>>>>> this
>>>>>> project. Also, sources and documentation are included in the bin.*
>>>>>> files
>>>>>> while the standalone.* files are just the jars and startup scripts.
>>>>>>
>>>>>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>>>>>
>>>>>>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>>>>>>
>>>>>>> (Note: I've created release instructions on the new wiki: <
>>>>>>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
>>>>>>> w+Release+Guide>)
>>>>>>>
>>>>>>> Artifacts:
>>>>>>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>>>>>>> svn revision 23048
>>>>>>>
>>>>>>> Site:
>>>>>>> http://musigma.org/chainsaw-site/
>>>>>>>
>>>>>>> Git:
>>>>>>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>>>>>>> tag: chainsaw-2.0.0-rc1
>>>>>>>
>>>>>>> All artifacts have been signed by my PGP key
>>>>>>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the
>>>>>>> Logging
>>>>>>> KEYS file.
>>>>>>>
>>>>>>> This vote will be open for at least 72 hours and requires at least 3
>>>>>>> +1
>>>>>>> votes and more +1 votes than -1 votes.
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker 
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker 
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker 
>>>>>
>>>>
>>>
>>
>>
>>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Here's my +1.

Site looks good, and it builds and runs.

Thanks Matt

On 11/10/17, Scott Deboy  wrote:
> Updated screenshot.
>
> On 11/10/17, Scott Deboy  wrote:
>> Awesome..I'll commit a new screenshot then.
>>
>> On 11/10/17, Ralph Goers  wrote:
>>> The web site doesn’t have to be locked into the release.  An image can
>>> be
>>> updated after the release pretty easily.
>>>
>>> Ralph
>>>
>>>
>>>> On Nov 10, 2017, at 1:03 PM, Scott Deboy  wrote:
>>>>
>>>> Would it be possible for me to push an updated screenshot and re-spin?
>>>>
>>>> On 11/10/17, Scott Deboy  wrote:
>>>>> Wow that screen shot looks ancient and ugly.  I should pull up
>>>>> something on the Mac with updated default colors - it looks much
>>>>> better.
>>>>>
>>>>> Scott
>>>>>
>>>>> On 11/10/17, Matt Sicker  wrote:
>>>>>> Oh, and in case it isn't obvious how to test this, you can extract
>>>>>> from
>>>>>> either the zip or tar.gz files and run the chainsaw script in bin/
>>>>>> corresponding to your operating system. Note that this crashes when
>>>>>> using
>>>>>> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>>>>>>
>>>>>> I built this using Java 1.8.0_111 on macOS 10.12.6.
>>>>>>
>>>>>> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>>>>>>
>>>>>>> Quick note: using the maven-release-plugin doesn't seem to work in
>>>>>>> this
>>>>>>> project. Also, sources and documentation are included in the bin.*
>>>>>>> files
>>>>>>> while the standalone.* files are just the jars and startup scripts.
>>>>>>>
>>>>>>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>>>>>>
>>>>>>>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>>>>>>>
>>>>>>>> (Note: I've created release instructions on the new wiki: <
>>>>>>>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
>>>>>>>> w+Release+Guide>)
>>>>>>>>
>>>>>>>> Artifacts:
>>>>>>>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>>>>>>>> svn revision 23048
>>>>>>>>
>>>>>>>> Site:
>>>>>>>> http://musigma.org/chainsaw-site/
>>>>>>>>
>>>>>>>> Git:
>>>>>>>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>>>>>>>> tag: chainsaw-2.0.0-rc1
>>>>>>>>
>>>>>>>> All artifacts have been signed by my PGP key
>>>>>>>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the
>>>>>>>> Logging
>>>>>>>> KEYS file.
>>>>>>>>
>>>>>>>> This vote will be open for at least 72 hours and requires at least
>>>>>>>> 3
>>>>>>>> +1
>>>>>>>> votes and more +1 votes than -1 votes.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker 
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker 
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker 
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

I had ran mvn clean site:site install and it worked.


On 11/11/17, Mikael Ståldal  wrote:
> On 2017-11-10 20:00, Matt Sicker wrote:
>> Artifacts:
>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>> svn revision 23048
>
> When I look at that URL, it says: Revision 23059
>

Re: Planning out what we can do to get Chainsaw back in the game

[Scott Deboy]

I'd love to hear what folks think of the user experience with the
'latest Chainsaw' and its feature set.

There are a ton of features.  It will be interesting to get a sense of
how many of those features we get 'for free' in any of these other UI
toolkits.  It was a lot of heavy lifting to get Swing to do what we
wanted.

Scott


On 11/11/17, Ole Ersoy  wrote:
> Kotlin is almost a duplicate of Typescript, so Javascript devs should be
> able to pickup on it fast.  There's a Typescript to Kotlin converter here:
>
> https://github.com/Kotlin/ts2kt
>
> Typescript is also supported in Electron:
>
> https://electron.atom.io/blog/2017/06/01/typescript
>
> So Kotlin should be a pretty good bridge between these worlds and opens up a
> lot of possibilities ... Suggested Kotlin to the Hipparchus group as well:
>
> https://github.com/Hipparchus-Math/hipparchus/issues/26
>
> A chainsaw implementation in Electron would provide a better developer and
> user experience I would think though ... as you can now use the latest
> Javascript frameworks (Angular / React) and all the packages that come with
> that ecosystem (Graphing, Widgets, etc.)
>
> https://scotch.io/tutorials/creating-desktop-applications-with-angularjs-and-github-electron
>
>
> On 11/11/2017 04:42 PM, Matt Sicker wrote:
>> I've been using Java for years, Scala for several months (all of OOP,
>> hybrid, and pure FP styles in different projects), and other languages in
>> the past. I've certainly found Scala to be useful in the Big Data space,
>> especially when using Spark, though I've also found it useful in projects
>> that consume Java APIs.
>>
>> As for Kotlin fitting well to a GUI app, based on its traction in the
>> Android GUI space, I had the same thought. Plus, this may attract more
>> contributors outside ASF who are interested in using Kotlin or working on
>> a
>> GUI app instead of low level Java bits.
>>
>> Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
>> pick
>> up on than Scala, so that also helps with adoption in theory.
>>
>> On 11 November 2017 at 10:23, Mikael Ståldal  wrote:
>>
>>> I have used both Java and Scala for several years, and I have been
>>> trying
>>> out Kotlin the latest months (for Android only).
>>>
>>> I would say it is definitely easier for a developer with primarily Java
>>> experience to pick up Kotlin than Scala, especially if that Java
>>> experience
>>> is predominately pre-Java8. If your primary experience is functional
>>> programming like Haskell, O'Caml or F#; then Scala is probably easier to
>>> pick up.
>>>
>>> Kotlin is gaining traction in Android, since it works well there. Scala
>>> is
>>> big in Big Data (Apache Spark etc) and to some extent in server/backend.
>>>
>>> Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
>>>
>>>
>>>
>>> On 2017-11-11 02:10, Gary Gregory wrote:
>>>
 I think Kotlin would be more approachable than Scala... thoughts?

 Gary

 On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:

 On 10 November 2017 at 16:17, Robert Middleton 
> wrote:
>
> What would the advantage be of using Scala vs just normal Java?
>> Mostly from a curiosity standpoint; I've never done Scala so I don't
>> know it works.
>>
>>
> The main advantage I can see is that most of the developers interested
> in
> working on v3 all prefer to work in Scala. I could go on and on about
> Scala
> over Java, but really, my comparison would all come down to functional
> programming over object oriented programming. When it comes to shared
> libraries like Log4j, I find Java far more appropriate and work in
> that
> space. In a GUI application where there is no real public API? I'd
> rather
> work in Scala. Kotlin was another option, but it seems like none of us
> really have experience there.
>
>
> Did you actually have trouble building?  I'm pretty sure that when I
>> built it a few months ago I simply opened up the project in Netbeans
>> and it built immediately as a maven project(although looking at the
>> POM it does look like it uses ant on the backend for some reason).
>>
>>
> Building the project is simple enough. I had issues with:
>
> 1. Running mvn clean install does not work by default unless you run
> "mvn
> site:site" before running "mvn install".
> 2. Doesn't build in Java 9.
> 3. The maven-release-plugin is not configured at all, so I had to do
> all
> release steps by hand instead.
>
> --
> Matt Sicker 
>
>
>>
>
>

Re: Planning out what we can do to get Chainsaw back in the game

[Scott Deboy]

It's definitely always been a relatively simple 'log event-focused'/tabular
data tool. Basically:

- Pull in data from sources (usually files-local or ssh-able)
- parse the data into fields
- route the data to one or more tabs
- render the events into a table
- support filter, search, colorize and sort-all using a common expression
syntax, sort of a simpler version of logstash's grok.

Dashboard/visualization support would be awesome, but this is both a real
time as well as offline analysis tool. Cursor-style previous/next page
event rendering would make it a terrible user experience IMO.

Scott



On Nov 11, 2017 8:22 PM, "Ole Ersoy"  wrote:

> I had a brief peek.  My first impression was that the whole thing needs a
> facelift.  I'm currently I'm reviewing the ELK stack with the Kibana user
> interface as well as fluentd and Zipkin. Something that unifies these
> things would be very attractive.  If the UI is modern then even more so.
> If we can deploy it as a progressive web app attachable to a GraphQL
> provider that gets feeds from Fluentd and the ELK stack that would
> definitely get Chainsaw back in the game.  I think you would have an easy
> time attracting a talent pool for something like that.  For example
> http://akveo.github.io/blur-admin/ is currently available on Github and
> has 8000 stars.  Could be the starting point for the next generation
> logging UI.
>
> Cheers,
>
> Ole
>
>
> On 11/11/2017 06:09 PM, Scott Deboy wrote:
>
>> I'd love to hear what folks think of the user experience with the
>> 'latest Chainsaw' and its feature set.
>>
>> There are a ton of features.  It will be interesting to get a sense of
>> how many of those features we get 'for free' in any of these other UI
>> toolkits.  It was a lot of heavy lifting to get Swing to do what we
>> wanted.
>>
>> Scott
>>
>>
>> On 11/11/17, Ole Ersoy  wrote:
>>
>>> Kotlin is almost a duplicate of Typescript, so Javascript devs should be
>>> able to pickup on it fast.  There's a Typescript to Kotlin converter
>>> here:
>>>
>>> https://github.com/Kotlin/ts2kt
>>>
>>> Typescript is also supported in Electron:
>>>
>>> https://electron.atom.io/blog/2017/06/01/typescript
>>>
>>> So Kotlin should be a pretty good bridge between these worlds and opens
>>> up a
>>> lot of possibilities ... Suggested Kotlin to the Hipparchus group as
>>> well:
>>>
>>> https://github.com/Hipparchus-Math/hipparchus/issues/26
>>>
>>> A chainsaw implementation in Electron would provide a better developer
>>> and
>>> user experience I would think though ... as you can now use the latest
>>> Javascript frameworks (Angular / React) and all the packages that come
>>> with
>>> that ecosystem (Graphing, Widgets, etc.)
>>>
>>> https://scotch.io/tutorials/creating-desktop-applications-wi
>>> th-angularjs-and-github-electron
>>>
>>>
>>> On 11/11/2017 04:42 PM, Matt Sicker wrote:
>>>
>>>> I've been using Java for years, Scala for several months (all of OOP,
>>>> hybrid, and pure FP styles in different projects), and other languages
>>>> in
>>>> the past. I've certainly found Scala to be useful in the Big Data space,
>>>> especially when using Spark, though I've also found it useful in
>>>> projects
>>>> that consume Java APIs.
>>>>
>>>> As for Kotlin fitting well to a GUI app, based on its traction in the
>>>> Android GUI space, I had the same thought. Plus, this may attract more
>>>> contributors outside ASF who are interested in using Kotlin or working
>>>> on
>>>> a
>>>> GUI app instead of low level Java bits.
>>>>
>>>> Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
>>>> pick
>>>> up on than Scala, so that also helps with adoption in theory.
>>>>
>>>> On 11 November 2017 at 10:23, Mikael Ståldal  wrote:
>>>>
>>>> I have used both Java and Scala for several years, and I have been
>>>>> trying
>>>>> out Kotlin the latest months (for Android only).
>>>>>
>>>>> I would say it is definitely easier for a developer with primarily Java
>>>>> experience to pick up Kotlin than Scala, especially if that Java
>>>>> experience
>>>>> is predominately pre-Java8. If your primary experience is functional
>

Re: Planning out what we can do to get Chainsaw back in the game

[Scott Deboy]

I'm playing with the high-level ES Java APIs now to see how easy it
will be to create a new Receiver that allows Chainsaw to query Elastic
Search directly.

It looks like it'll be pretty simple.

Scott

On 11/12/17, Matt Sicker  wrote:
> I'm heavily opposed to myself being involved in any non-trivial web UI code
> until some semblance of sanity arises in that space (see for example the
> Elm programming language which does a good job toward accomplishing some of
> that). Electron, while a cool piece of technology, is not my ideal way to
> implement a GUI. Since we're all familiar with the JVM and its tech, Swing
> or JavaFX are some of the best bets there. If we were looking outside that
> space, I'd recommend using the Qt framework which would be more of a C++
> thing at that point (though I know it supports all sorts of scripting
> things nowadays).
>
> Allowing Chainsaw to integrate with remote logging/monitoring services for
> obtaining log data and whatnot, however, would be a neat addition.
>
> I haven't had a chance to dive into the code yet, but I'd imagine that
> there may be some sort of boundary in place (or can be put in place)
> between the UI and the logic such that multiple UIs can reuse the same
> code. That sort of pattern is not specific to web development. :)
>
> On 12 November 2017 at 08:50, Mikael Ståldal  wrote:
>
>> Having said that, I don't mean that Ole Ersoy's idea is inherently bad.
>> But it should be a new independent project (possibly in Apache Logging
>> Services).
>>
>>
>>
>> On 2017-11-12 14:27, Mikael Ståldal wrote:
>>
>>> To me, that sound like transforming it into something completely
>>> different, and a use case which there already exists quite some other
>>> tools
>>> for already.
>>>
>>> Shouldn't we keep Chainsaw as a stand-alone desktop UI app?
>>>
>>>
>>> On 2017-11-12 05:22, Ole Ersoy wrote:
>>>
>>>> I had a brief peek.  My first impression was that the whole thing needs
>>>> a facelift.  I'm currently I'm reviewing the ELK stack with the Kibana
>>>> user
>>>> interface as well as fluentd and Zipkin. Something that unifies these
>>>> things would be very attractive.  If the UI is modern then even more
>>>> so.
>>>> If we can deploy it as a progressive web app attachable to a GraphQL
>>>> provider that gets feeds from Fluentd and the ELK stack that would
>>>> definitely get Chainsaw back in the game.  I think you would have an
>>>> easy
>>>> time attracting a talent pool for something like that.  For example
>>>> http://akveo.github.io/blur-admin/ is currently available on Github and
>>>> has 8000 stars.  Could be the starting point for the next generation
>>>> logging UI.
>>>>
>>>> Cheers,
>>>>
>>>> Ole
>>>>
>>>>
>>>> On 11/11/2017 06:09 PM, Scott Deboy wrote:
>>>>
>>>>> I'd love to hear what folks think of the user experience with the
>>>>> 'latest Chainsaw' and its feature set.
>>>>>
>>>>> There are a ton of features.  It will be interesting to get a sense of
>>>>> how many of those features we get 'for free' in any of these other UI
>>>>> toolkits.  It was a lot of heavy lifting to get Swing to do what we
>>>>> wanted.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>> On 11/11/17, Ole Ersoy  wrote:
>>>>>
>>>>>> Kotlin is almost a duplicate of Typescript, so Javascript devs should
>>>>>> be
>>>>>> able to pickup on it fast.  There's a Typescript to Kotlin converter
>>>>>> here:
>>>>>>
>>>>>> https://github.com/Kotlin/ts2kt
>>>>>>
>>>>>> Typescript is also supported in Electron:
>>>>>>
>>>>>> https://electron.atom.io/blog/2017/06/01/typescript
>>>>>>
>>>>>> So Kotlin should be a pretty good bridge between these worlds and
>>>>>> opens up a
>>>>>> lot of possibilities ... Suggested Kotlin to the Hipparchus group as
>>>>>> well:
>>>>>>
>>>>>> https://github.com/Hipparchus-Math/hipparchus/issues/26
>>>>>>
>>>>>> A chainsaw implementation in Electron would provide a better
>>>>>> developer
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

That's right - we don't bundle in a JMS jar, although users can add
one to the classpath to use the JMSReceiver.

On 11/12/17, Mikael Ståldal  wrote:
> When running Chainsaw, I see this error message:
>
> Failed to locate Receiver class:org.apache.log4j.net.JMSReceiver, looks
> like a dependent class is missing from the classpath
> java.lang.NoClassDefFoundError: javax/jms/MessageListener
>
> It seems to work anyway (without JMX support I suppose) though. But I
> guess some jar file with that class should be on the classpath?
>
>
> On 2017-11-10 20:00, Matt Sicker wrote:
>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>
>> (Note: I've created release instructions on the new wiki: <
>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)
>>
>> Artifacts:
>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>> svn revision 23048
>>
>> Site:
>> http://musigma.org/chainsaw-site/
>>
>> Git:
>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>> tag: chainsaw-2.0.0-rc1
>>
>> All artifacts have been signed by my PGP key
>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
>> KEYS
>> file.
>>
>> This vote will be open for at least 72 hours and requires at least 3 +1
>> votes and more +1 votes than -1 votes.
>>
>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Fixed.

On 11/12/17, Mikael Ståldal  wrote:
> In the About text, it says:
>
> Please send questions, bug reports and/or feature requests to
> log4j-...@logging.apache.org
>
> which is obsolete.
>
>
> On 2017-11-10 20:00, Matt Sicker wrote:
>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>
>> (Note: I've created release instructions on the new wiki: <
>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)
>>
>> Artifacts:
>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>> svn revision 23048
>>
>> Site:
>> http://musigma.org/chainsaw-site/
>>
>> Git:
>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>> tag: chainsaw-2.0.0-rc1
>>
>> All artifacts have been signed by my PGP key
>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
>> KEYS
>> file.
>>
>> This vote will be open for at least 72 hours and requires at least 3 +1
>> votes and more +1 votes than -1 votes.
>>
>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

I think we can either fix or remove that menu item from the menu after
the release - I don't know how useful it is.

Scott

On 11/12/17, Mikael Ståldal  wrote:
> When starting Chainsaw, I see this warning:
>
> Could not find any local JavaDocs, you might want to consider running
> 'ant javadoc'. The release version will be able to access Javadocs from
> the Apache website.
>
> And accessing Javadocs from the Help menu does not work.
>
>
>
> On 2017-11-10 20:00, Matt Sicker wrote:
>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>
>> (Note: I've created release instructions on the new wiki: <
>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)
>>
>> Artifacts:
>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>> svn revision 23048
>>
>> Site:
>> http://musigma.org/chainsaw-site/
>>
>> Git:
>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>> tag: chainsaw-2.0.0-rc1
>>
>> All artifacts have been signed by my PGP key
>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
>> KEYS
>> file.
>>
>> This vote will be open for at least 72 hours and requires at least 3 +1
>> votes and more +1 votes than -1 votes.
>>
>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

That's right -forgot we rev'd to 2.1 internally (info.plist, release
notes, couple other places).

Would it be easiest to release the new version as 2.1.0.0 instead of
2.0.0-rc1?  Otherwise I could downgrade 2.1 refs, we never had an
official release with that rev.

Scott

On 11/12/17, Mikael Ståldal  wrote:
> In release notes in the app, it says version 2.1.
>
>
> On 2017-11-10 20:00, Matt Sicker wrote:
>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>
>> (Note: I've created release instructions on the new wiki: <
>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)
>>
>> Artifacts:
>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>> svn revision 23048
>>
>> Site:
>> http://musigma.org/chainsaw-site/
>>
>> Git:
>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>> tag: chainsaw-2.0.0-rc1
>>
>> All artifacts have been signed by my PGP key
>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
>> KEYS
>> file.
>>
>> This vote will be open for at least 72 hours and requires at least 3 +1
>> votes and more +1 votes than -1 votes.
>>
>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

I don't recall why - it was a while back :)

Yes, I think 2.1.0-rc1 would make sense, once we fix the /bin directory issue.

On 11/12/17, Matt Sicker  wrote:
> On 12 November 2017 at 13:53, Scott Deboy  wrote:
>
>> That's right -forgot we rev'd to 2.1 internally (info.plist, release
>> notes, couple other places).
>>
>
> Any particular reason?
>
>
>> Would it be easiest to release the new version as 2.1.0.0 instead of
>> 2.0.0-rc1?  Otherwise I could downgrade 2.1 refs, we never had an
>> official release with that rev.
>>
>
> I could re-roll as 2.1.0-rc1 (or rc2?). I chose 2.0.0 since there's no tags
> or releases for any 2.x release at all, so it seemed like a logical
> starting point.
>
> And thanks for testing! We should be able to clean up for a proper 2.x
> release. :)
>
> --
> Matt Sicker 
>

Re: [Chainsaw] Next step: Log4j 2

[Scott Deboy]

Awesome!

Re: appenders:

We went through a couple of code re-orgs back in 2011 and 2013, some
stuff was moved out of Chainsaw to apache-log4j-extras.  Looks like
some was left behind.

You can define Chainsaw as an appender yourself - so the UI starts if
it's in the log4j xml config file.

Because Chainsaw is an appender itself (a graphical one), Chainsaw
hooks in to the existing log4j configuration dynamically as an
appender to receive events, and we use that plumbing to process all
events received by a Receiver.

After building a LoggingEvent from the source, a Receiver pushes the
event to the appender framework by calling:

// get the "local" logger for this event from the
// configured repository.
Logger localLogger =
getLoggerRepository().getLogger(event.getLoggerName());

// if the logger level is greater or equal to the level
// of the event, use the logger to append the event.
if (event.getLevel()
.isGreaterOrEqual(localLogger.getEffectiveLevel())) {
// call the loggers appenders to process the event
localLogger.callAppenders(event);
}
  }


Scott


On 11/20/17, Mikael Ståldal  wrote:
> I took a look at the Chainsaw source code, and tried to remove its
> dependency on Log4j 1 and migrate to Log4j 2.
>
> That was not easy, Chainsaw heavily depends on intricate Log4j 1
> implementation details. There is a lot of tedious but straight-forward
> search/replace kind of work to do. But quite some more tricky stuff
> which I couldn't figure out all of.
>
> I haven't yet got it to compile, and I got tired of it for the moment.
> But I have pushed my (unfinished) work to branch "log4j-2".
>
> Maybe we need to take another apporach. There seems to be quote some
> code there which is more or less unused, like all those Appenders (why
> does Chainsaw need appenders? shouldn't it receive log events?).
>
> Maybe we should try to clean up the current codebase and remove as much
> unused and obsolete stuff (stuff that will be obsolete when we have
> migrated to Log4j 2) as possible before migrating?
>

Re: Log4JNA

[Scott Deboy]

+1

On Nov 23, 2017 10:20 AM, "Ralph Goers"  wrote:

> Or ask the author if he would like it to become part of Logging Services.
>
> Ralph
>
> > On Nov 23, 2017, at 7:51 AM, Gary Gregory 
> wrote:
> >
> > On Thu, Nov 23, 2017 at 4:10 AM, Remko Popma 
> wrote:
> >
> >> Interesting:
> >> https://github.com/dblock/log4jna/blob/master/README.md
> >>
> >> Maybe we should link to this from our site somewhere. Like a section on
> >> 3rd party appenders or so?
> >
> >
> > +1!
> >
> > Gary
>
>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

I finally looked at this.  I pushed a change to app assembler config
to make the bin directory executable, and updated HOWTOBUILD to
mention you need to run mvn site:site first.

Can we resin?

On 11/13/17, Matt Sicker  wrote:
> Another thing I noticed is that the downloads page needs to be updated to
> link to the (future) dist URLs instead of ones in the site's directory (no
> proper mirroring in the old links).
>
> On 12 November 2017 at 19:25, Scott Deboy  wrote:
>
>> I don't recall why - it was a while back :)
>>
>> Yes, I think 2.1.0-rc1 would make sense, once we fix the /bin directory
>> issue.
>>
>> On 11/12/17, Matt Sicker  wrote:
>> > On 12 November 2017 at 13:53, Scott Deboy 
>> > wrote:
>> >
>> >> That's right -forgot we rev'd to 2.1 internally (info.plist, release
>> >> notes, couple other places).
>> >>
>> >
>> > Any particular reason?
>> >
>> >
>> >> Would it be easiest to release the new version as 2.1.0.0 instead of
>> >> 2.0.0-rc1?  Otherwise I could downgrade 2.1 refs, we never had an
>> >> official release with that rev.
>> >>
>> >
>> > I could re-roll as 2.1.0-rc1 (or rc2?). I chose 2.0.0 since there's no
>> tags
>> > or releases for any 2.x release at all, so it seemed like a logical
>> > starting point.
>> >
>> > And thanks for testing! We should be able to clean up for a proper 2.x
>> > release. :)
>> >
>> > --
>> > Matt Sicker 
>> >
>>
>
>
>
> --
> Matt Sicker 
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Matt, would you mind re-spinning a new build at 2.1.0-rc1?

On 1/19/18, Scott Deboy  wrote:
> I finally looked at this.  I pushed a change to app assembler config
> to make the bin directory executable, and updated HOWTOBUILD to
> mention you need to run mvn site:site first.
>
> Can we resin?
>
> On 11/13/17, Matt Sicker  wrote:
>> Another thing I noticed is that the downloads page needs to be updated to
>> link to the (future) dist URLs instead of ones in the site's directory
>> (no
>> proper mirroring in the old links).
>>
>> On 12 November 2017 at 19:25, Scott Deboy  wrote:
>>
>>> I don't recall why - it was a while back :)
>>>
>>> Yes, I think 2.1.0-rc1 would make sense, once we fix the /bin directory
>>> issue.
>>>
>>> On 11/12/17, Matt Sicker  wrote:
>>> > On 12 November 2017 at 13:53, Scott Deboy 
>>> > wrote:
>>> >
>>> >> That's right -forgot we rev'd to 2.1 internally (info.plist, release
>>> >> notes, couple other places).
>>> >>
>>> >
>>> > Any particular reason?
>>> >
>>> >
>>> >> Would it be easiest to release the new version as 2.1.0.0 instead of
>>> >> 2.0.0-rc1?  Otherwise I could downgrade 2.1 refs, we never had an
>>> >> official release with that rev.
>>> >>
>>> >
>>> > I could re-roll as 2.1.0-rc1 (or rc2?). I chose 2.0.0 since there's no
>>> tags
>>> > or releases for any 2.x release at all, so it seemed like a logical
>>> > starting point.
>>> >
>>> > And thanks for testing! We should be able to clean up for a proper 2.x
>>> > release. :)
>>> >
>>> > --
>>> > Matt Sicker 
>>> >
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Sure

On Jan 20, 2018 9:04 AM, "Matt Sicker"  wrote:

> Wouldn't it be 2.0.0-rc2? Also, good timing: I can cut a new RC in the next
> few hours.
>
> On 20 January 2018 at 09:47, Scott Deboy  wrote:
>
> > Matt, would you mind re-spinning a new build at 2.1.0-rc1?
> >
> > On 1/19/18, Scott Deboy  wrote:
> > > I finally looked at this.  I pushed a change to app assembler config
> > > to make the bin directory executable, and updated HOWTOBUILD to
> > > mention you need to run mvn site:site first.
> > >
> > > Can we resin?
> > >
> > > On 11/13/17, Matt Sicker  wrote:
> > >> Another thing I noticed is that the downloads page needs to be updated
> > to
> > >> link to the (future) dist URLs instead of ones in the site's directory
> > >> (no
> > >> proper mirroring in the old links).
> > >>
> > >> On 12 November 2017 at 19:25, Scott Deboy 
> > wrote:
> > >>
> > >>> I don't recall why - it was a while back :)
> > >>>
> > >>> Yes, I think 2.1.0-rc1 would make sense, once we fix the /bin
> directory
> > >>> issue.
> > >>>
> > >>> On 11/12/17, Matt Sicker  wrote:
> > >>> > On 12 November 2017 at 13:53, Scott Deboy 
> > >>> > wrote:
> > >>> >
> > >>> >> That's right -forgot we rev'd to 2.1 internally (info.plist,
> release
> > >>> >> notes, couple other places).
> > >>> >>
> > >>> >
> > >>> > Any particular reason?
> > >>> >
> > >>> >
> > >>> >> Would it be easiest to release the new version as 2.1.0.0 instead
> of
> > >>> >> 2.0.0-rc1?  Otherwise I could downgrade 2.1 refs, we never had an
> > >>> >> official release with that rev.
> > >>> >>
> > >>> >
> > >>> > I could re-roll as 2.1.0-rc1 (or rc2?). I chose 2.0.0 since there's
> > no
> > >>> tags
> > >>> > or releases for any 2.x release at all, so it seemed like a logical
> > >>> > starting point.
> > >>> >
> > >>> > And thanks for testing! We should be able to clean up for a proper
> > 2.x
> > >>> > release. :)
> > >>> >
> > >>> > --
> > >>> > Matt Sicker 
> > >>> >
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker 
> > >>
> > >
> >
>
>
>
> --
> Matt Sicker 
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc2

[Scott Deboy]

+1

Pulled the git tag, built it and started Chainsaw from the standalone
tarball and zips.

Wandered through the website - there is cleanup to be done, but that's
work that can be done post-release.

Scott

On 1/20/18, Matt Sicker  wrote:
> This is a vote to release Apache Chainsaw 2.0.0-rc2
>
> Source and binary artifacts:
>
> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>
> Committed under SVN revision 24337.
>
> Site:
>
> http://musigma.org/chainsaw-site/
> https://github.com/jvz/chainsaw-site
>
> Git:
>
> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
> tag: chainsaw-2.0.0-rc2 <
> https://git-wip-us.apache.org/repos/asf?p=logging-chainsaw.git;a=tag;h=a9633a9bc4e7d635b893f7697e4a3dbae596795d
>>
>
> Artifacts signed by my key id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D.
>
> This vote will be open for at least 72 hours and requires at least 3 +1
> votes and no more -1 votes than +1 votes.
>
> --
> Matt Sicker 
>

Re: [log4j] The shape of Log4j

[Scott Deboy]

I recall the log4j logging-parent nightmare of a number of years back.
Please let's not re-visit that.

https://github.com/apache/logging-parent/blob/master/pom.xml

Scott

On Jan 21, 2018 4:51 PM, "Remko Popma"  wrote:

> Log4j2 is not like Maven. Maven (I assume) has a plugin API. Log4j2
> modules depend on the internals of log4j-core.
>
> I agree with Gary that not being able to verify that a core change doesn’t
> break any modules when they live outside the main project is a valid
> concern.
>
> Why are we talking about modules and repos when the issue is that it takes
> too long to do a release? Maven reports most modules as taking a handful of
> seconds to build.
>
> I keep thinking:
>
> 1. We’re running the tests twice during a release. Let’s change this.
> Logically, once should be enough. What prevents us from doing this?
>
> 2. Core tests take unnecessarily long. By running some tests in parallel
> and some other tests without forking I have hope we can run all core tests
> in ~15 minutes.
>
> Won’t those two changes be much more impactful in reducing the release
> time than any amount of module or repo reshuffling?
>
> Remko
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Jan 22, 2018, at 8:14, Ralph Goers 
> wrote:
> >
> > I am very much against the idea of a single repo. Yes, you can have
> multiple projects in the repo but I am not sure how that can be sanely
> released. I much prefer the model that Maven has taken. They are now using
> gitbox [1] which seems to allow GitHub to be the primary repo. Every Maven
> plugin is individually released. Scroll down the link below to the Maven
> section and you can see all the plugin repos.
> >
> > The upside to this is that it are:
> >1. It is far easier to perform releases of the individual components.
> >2. It is much easier to accept plugin contributions.
> > The downsides are:
> >1. A page like https://maven.apache.org/plugins/ <
> https://maven.apache.org/plugins/> is needed to keep track of the plugin
> versions.
> >2. It could make sense to have log4j-parent and log4j-bom projects.
> The first to help keep the builds similar and the second to help customers
> pick up the latest versions.
> >
> > Ralph
> >
> > [1] https://gitbox.apache.org/repos/asf  repos/asf>
> >
> >> On Jan 21, 2018, at 8:55 AM, Gary Gregory 
> wrote:
> >>
> >> Hi All,
> >>
> >> I am writing this to in an effort to understand how we can manage and
> grow
> >> Log4j. I use the term 'grow' not in the 'bigger is better' sense but
> more
> >> in the maturing sense.
> >>
> >> I am prompted to write this by Ralph's comment that log4j-core and the
> main
> >> repo is too big and that releases take too long make, partially
> prompted by
> >> my addition of a new module called log4j-jdbc-dbcp2 which currently
> >> contains one small class with a dependency on Apache Commons DBCP 2.
> >>
> >> I would like to express my gratitude at Ralph's efforts to revitalized
> >> Log4j and performing most release management duties. Thank you Ralph!
> >>
> >> I can see two main orthogonal issues:
> >> - The size of the git repo.
> >> - The size of the log4j-core module.
> >>
> >> Ralph has proposed that new modules like log4j-jdbc-dbcp2 be moved to
> >> another 'plugin' repo.
> >>
> >> I really dislike this idea:
> >> - The plugin repo has never been released. Not that one releases a repo
> but
> >> you get the point.
> >> - How do you keep things in sync between repos and code when we have no
> >> official 'core' SPI.
> >>
> >> For my money, we should keep _everything_ in one repo. Good enough for
> >> Google, so good enough for me. What we release out of that repo is a
> >> different story and what I would like to discuss next.
> >>
> >> This is not the same as Maven plugins IMO but the case could be made
> for it
> >> I suppose where a lot/most plugins live in their own repos. It is not
> the
> >> same as with Maven IMO because our plugins rely on log4j-core and it's
> >> guts, for which we only make loose compatibility guarantees -- as
> opposed
> >> to log4j-core where we are strict(er). Maven OTOH, has a API for plugin
> >> auteurs.
> >>
> >> For example, log4j-jdbc-dbcp2 replies on the guts of log4j-core and we
> have
> >> no 'official' core SPI, so splitting it off into a separate repo would
> >> greatly increase the risk of it falling out of sync. It is just so much
> >> more easier to maintain when it is all in one repo.
> >>
> >> My proposal is to:
> >>
> >> - Put everything back into one repo (Chainsaw too?)
> >> - Define a core SPI for plugin writers where we make some statement
> about
> >> BC, more than the casual 'we try not break stuff.'
> >> - Defining what Log4j project 'components' we have and release based on
> >> that. For example, today, all of the main Log4j repo is one component
> with
> >> many modules. Chainsaw would be another component of the Log4j project.
> >> Maybe we need to redefine com

Re: [log4j] The shape of Log4j

[Scott Deboy]

Correcting my prior comment: the nightmare I was referring to was the
ugliness we did and un-did related to the never-released receivers and
'component' companions.  Definitely feels like deja vu.

https://github.com/apache/log4j-component/blob/trunk/pom.xml

apache-log4j-companions-parent etc etc


On 1/22/18, Matt Sicker  wrote:
> Using Maven profiles could help, though when tagging a release, if we
> didn't release every module within, then it'd get out of sync anyways. Then
> it would still require building every single component in each release,
> even when said components haven't changed at all.
>
> On 22 January 2018 at 15:50, Gary Gregory  wrote:
>
>> Coming back around to the idea of One Repo to Rule Them All*TM* ... what
>> if
>> we used Maven profiles to separate out the "main" build from "other"
>> builds?
>>
>> All that is needed to move modules from one build to another is just to
>> edit the profile!
>>
>> Gary
>>
>> On Mon, Jan 22, 2018 at 12:48 PM, Ralph Goers
>> 
>> wrote:
>>
>> > I don’t see why this work would require 3.0 as we aren’t planning on
>> > breaking any contracts to do this.
>> >
>> > As I’ve said, I am not tied to each plugin having its own repo. I am OK
>> > with these options; a) each plugin has its own repo and site and is
>> > released independently, b) we use the plugins repo and move all the
>> > more
>> > lightly used components there. It would have its own site, or c) we
>> > group
>> > plugins by how they are related (RDBMS, NoSQL, “Transport” (Flume or
>> > similar) with each having its own site.
>> >
>> > Obviously I do not consider continuing to add new plugins to the main
>> > build as one of the options.
>> >
>> > Ralph
>> >
>> > > On Jan 22, 2018, at 12:36 PM, Matt Sicker  wrote:
>> > >
>> > > This whole conversation just reminds me of all the times in the past
>> > > I
>> > > suggested full modularization of the core API/SPI. I think such an
>> effort
>> > > would make sense in a 3.0 release.
>> > >
>> > > In 2.x, perhaps what we can do is define a stable plugin API based on
>> > what
>> > > we already have. Since we're still supporting Java 7, I'd suggest we
>> make
>> > > abstract classes be the stable part of the API since we don't have
>> > default
>> > > methods on interfaces here.
>> > >
>> > > And yes, the GitBox integration thing sounds neat, particularly for
>> code
>> > > review, though that's a separate topic entirely.
>> > >
>> > > On 22 January 2018 at 00:37, Gary Gregory 
>> > wrote:
>> > >
>> > >> On Sun, Jan 21, 2018 at 4:14 PM, Ralph Goers <
>> > ralph.go...@dslextreme.com>
>> > >> wrote:
>> > >>
>> > >>> I am very much against the idea of a single repo. Yes, you can have
>> > >>> multiple projects in the repo but I am not sure how that can be
>> sanely
>> > >>> released. I much prefer the model that Maven has taken. They are
>> > >>> now
>> > >> using
>> > >>> gitbox [1] which seems to allow GitHub to be the primary repo.
>> > >>
>> > >>
>> > >> GitHub is a distracting tangent here IMO. I really like GitHub's
>> > >> code
>> > >> commenting feature, but it should not matter if we use Apache's Git
>> > hosted
>> > >> repos or GitHub's. So I'm not sure why we are mixing GitHub in the
>> > >> conversation... ;-)
>> > >>
>> > >> Gary
>> > >>
>> > >>
>> > >>> Every Maven plugin is individually released. Scroll down the link
>> below
>> > >> to
>> > >>> the Maven section and you can see all the plugin repos.
>> > >>>
>> > >>> The upside to this is that it are:
>> > >>>1. It is far easier to perform releases of the individual
>> > >>> components.
>> > >>>2. It is much easier to accept plugin contributions.
>> > >>> The downsides are:
>> > >>>1. A page like https://maven.apache.org/plugins/ <
>> > >>> https://maven.apache.org/plugins/> is needed to keep track of the
>> > plugin
>> > >>> versions.
>> > >>>2. It could make sense to have log4j-parent and log4j-bom
>> > >>> projects. The first to help keep the builds similar and the second
>> > >>> to
>> > >> help
>> > >>> customers pick up the latest versions.
>> > >>>
>> > >>> Ralph
>> > >>>
>> > >>> [1] https://gitbox.apache.org/repos/asf > > >>> repos/asf>
>> > >>>
>> >  On Jan 21, 2018, at 8:55 AM, Gary Gregory 
>> > >>> wrote:
>> > 
>> >  Hi All,
>> > 
>> >  I am writing this to in an effort to understand how we can manage
>> and
>> > >>> grow
>> >  Log4j. I use the term 'grow' not in the 'bigger is better' sense
>> >  but
>> > >> more
>> >  in the maturing sense.
>> > 
>> >  I am prompted to write this by Ralph's comment that log4j-core and
>> the
>> > >>> main
>> >  repo is too big and that releases take too long make, partially
>> > >> prompted
>> > >>> by
>> >  my addition of a new module called log4j-jdbc-dbcp2 which
>> >  currently
>> >  contains one small class with a dependency on Apache Commons DBCP
>> >  2.
>> > 
>> >  I would like to express my gratitude at Ra

Re: [log4j] The shape of Log4j

[Scott Deboy]

My recollection is vague, tied to pom machinations supporting a
similar separation for the 'log4j companions': outside of core log4j -
chainsaw, component, extras, receivers and zeroconf'

Some of the issues I recall having to deal with when we had the
generic 'component' module:

 - Some classes start out in one module, like the 'component' module,
but then it turns out something in core could benefit from that same
class, so it's pulled in to core.  This could result in a class rename
or package move in the process in order to match the structure of
core, naming conventions, etc.

If we did this only at a 'backward-compatibility breaking' boundary
that would be ok, it can just be confusing and unnecessary if we have
one module.

We also had the entire 'component' module sucked in to the 'receivers'
module when we felt that the separation wasn't useful, with Receivers
eventually getting pulled in to Chainsaw, where it didn't really
belong IMO..

So my worry is about things getting 'promoted and moved' because they
are now useful somewhere else, and the confusion that can ensue.


On 1/22/18, Gary Gregory  wrote:
> On Mon, Jan 22, 2018 at 3:54 PM, Ralph Goers 
> wrote:
>
>>
>>
>> > On Jan 22, 2018, at 3:44 PM, Gary Gregory 
>> wrote:
>> >
>> > On Mon, Jan 22, 2018 at 3:25 PM, Matt Sicker  wrote:
>> >
>> >> The profiles idea would help a lot for local development and making it
>> >> easier to run the relevant unit tests when modifying code. This
>> >> wouldn't
>> >> really help the release process, though, as we'd either need to
>> >> release
>> >> everything in the repo at once, or we'd end up with unreleased modules
>> >> being tagged on release of anything else in the same repo.
>> >>
>> >
>> > Ah... but you COULD make it help in the release just as well but
>> > putting
>> > what you are releasing into the main profile! That's the beauty of it.
>> > Sure, you'd tag the whole thing as one. Presumably, you'd think the RM
>> > would make sure at least everything compiles ;-)
>>
>> I don’t understand. If I perform a release for 2.11.0 and skip certain
>> modules they are not going to have their versions updated. They will be
>> pointing at 2.11.0-SNAPSHOT as a parent even though the parent has been
>> changed to 2.11.1-SNAPSHOT.
>>
>
> The way I see it is that you'd update the POM versions _as if_ you were to
> release and had released the modules that in fact are skipped. For example,
> if log4j-foo is not in the main-modules profile, it's versions would go
> from 2.11.0-SNAPSHOT to 2.11.1-SNAPSHOT. I suppose that might means an
> adjustment to a current step or an extra step.
>
> Gary
>
>
>>
>> If I assume all the pom versions are the same at 2.11.0-SNAPSHOT and only
>> want to release the mongodb plugin it will update the parent pom and
>> mongodb pom to the next version - let’s say 2.11.1-SNAPSHOT. I now cannot
>> release log4j as 2.11.0 since the parent pom has already released 2.11.0.
>> So you are going to have version numbers skipping all around.
>>
>> Ralph
>>
>>
>>
>

Re: [log4j] The shape of Log4j

[Scott Deboy]

+1

The added complexity of managing the various repo builds and compatibility
outweighs the build-time related cost of adding this code to core, easily.

Just consider the time required to RM these other repos. There is no
savings here to be found.

Scott

On Jan 24, 2018 6:20 PM, "Remko Popma"  wrote:

> I’m still not convinced that moving the items that Ralph enumerated out of
> core will make a significant difference in the time it takes to do a
> release (I believe other measures will be more effective), but fine.
>
> If Ralph wants this as a precondition to continue to perform the Log4j2
> releases then I can accept that. I’m not planning to start doing the Log4j2
> releases and I’m grateful that others are willing to do so.
>
> However, an important question that needs to be answered before we do this
> is: how do we detect when changes in the main Log4j2 project broke one of
> the plugins when they live in another repo?
>
> Creating a plugin API is one option but this will take time to design,
> develop and test.
>
> One possible alternative: Can we set up a continuous integration service
> that builds the main project together with the plugins subproject? (We
> probably need this regardless of whether there is a plugin API or not.) I’m
> open to other solutions but we do need some process in place to detect
> breaking changes.
>
> FYI I strongly feel the perf module should stay in the main project/repo
> or it won’t be useable.
>
> Finally, I think breaking up log4j-plugins into many separate repos is not
> a good idea. It may sound nice on the surface but the overhead is large.
> Are the people pushing for the repo-per-module idea willing to do the
> release work for these plugins? And is everyone else willing to review and
> vote for 10 plugin releases instead of just one? And integrate 10 websites
> instead of one?
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Jan 25, 2018, at 9:45, Matt Sicker  wrote:
> >
> > I'm going to sum up my view here: if we split up repos to include plugins
> > that depend on log4j-core, then we first need to define and release a
> > stable plugin API. If we can't guarantee BC for plugins, then there's no
> > realistic way to both split out additional plugins and have them be
> > officially endorsed plugins. If said plugins were completely outside
> Apache
> > (e.g., personal GitHub pages), then it wouldn't be as strict.
> >
> > Also, I find it hard to believe that Google really uses a monorepo
> anymore.
> > Such an idea wouldn't work too well with software that isn't continuously
> > released.
> >
> > I suppose that's an alternative: I'd be open to splitting up repos
> however
> > desired if releases were continually published to avoid version number
> > synchronisation efforts, but I'm not so sure how well that meshes with
> the
> > Apache Way for releasing software.
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc2

[Scott Deboy]

Thanks Matt!  Looks good!

Scott

On 1/25/18, Matt Sicker  wrote:
> This vote passes with 3 +1 votes from Scott Deboy, Remko Popma, and myself.
> I'll be following up with an announcement thread shortly.
>
> On 24 January 2018 at 18:50, Matt Sicker  wrote:
>
>> So far so good with this vote. I'll finish the release process tomorrow
>> morning (approximately 15 hours from the time of this email) if there are
>> no showstopper before then.
>>
>> On 22 January 2018 at 17:08, Remko Popma  wrote:
>>
>>> +1
>>>
>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>
>>> > On Jan 23, 2018, at 7:29, Matt Sicker  wrote:
>>> >
>>> > I'll add my +1 from earlier. We still need another +1, though it's
>>> > only
>>> > been two days so far, so we still have time.
>>> >
>>> >> On 20 January 2018 at 16:54, Matt Sicker  wrote:
>>> >>
>>> >> I've committed the updated .asc files in revision 24339. MD5 and
>>> SHA-512
>>> >> hashes are still the same.
>>> >>
>>> >> Do note that you can also verify the git tag using the same gpg key
>>> >> via
>>> >> this command:
>>> >>
>>> >> git tag --verify chainsaw-2.0.0-rc2
>>> >>
>>> >>> On 20 January 2018 at 16:47, Matt Sicker  wrote:
>>> >>>
>>> >>> I didn't change my key (last 8 characters are the same as the short
>>> id).
>>> >>> Looks like I might have signed it wrong.
>>> >>>
>>> >>> On 20 January 2018 at 15:01, ralph.goers dslextreme.com <
>>> >>> ralph.go...@dslextreme.com> wrote:
>>> >>>
>>> >>>> Did you use a new signing key? When I try to verify I get
>>> >>>>
>>> >>>> gpg --verify apache-chainsaw-2.0.0-bin.tar.gz.asc
>>> >>>> apache-chainsaw-2.0.0-bin.tar.gz
>>> >>>> gpg: Signature made Fri Nov 10 11:41:12 2017 MST
>>> >>>> gpg:using RSA key 9D0A56AAA0D60E0C0C7DCCC0B4C708
>>> >>>> 93B62BABE8
>>> >>>> gpg: BAD signature from "Matthew Sicker (Signing Key) <
>>> >>>> mattsic...@apache.org>" [undefined]
>>> >>>>
>>> >>>> Ralph
>>> >>>>
>>> >>>>
>>> >>>> - Original Message -
>>> >>>> From: "Matt Sicker" 
>>> >>>> To: "Apache Logging Developers List" 
>>> >>>> Sent: Saturday, January 20, 2018 10:42:21 AM
>>> >>>> Subject: [VOTE] Release Apache Chainsaw 2.0.0-rc2
>>> >>>>
>>> >>>> This is a vote to release Apache Chainsaw 2.0.0-rc2
>>> >>>>
>>> >>>> Source and binary artifacts:
>>> >>>>
>>> >>>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>>> >>>>
>>> >>>> Committed under SVN revision 24337.
>>> >>>>
>>> >>>> Site:
>>> >>>>
>>> >>>> http://musigma.org/chainsaw-site/
>>> >>>> https://github.com/jvz/chainsaw-site
>>> >>>>
>>> >>>> Git:
>>> >>>>
>>> >>>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>>> >>>> tag: chainsaw-2.0.0-rc2 <
>>> >>>> https://git-wip-us.apache.org/repos/asf?p=logging-chainsaw.g
>>> >>>> it;a=tag;h=a9633a9bc4e7d635b893f7697e4a3dbae596795d
>>> >>>>>
>>> >>>>
>>> >>>> Artifacts signed by my key id 748F15B2CF9BA8F024155E6ED7C92B
>>> 70FA1C814D.
>>> >>>>
>>> >>>> This vote will be open for at least 72 hours and requires at least
>>> >>>> 3
>>> +1
>>> >>>> votes and no more -1 votes than +1 votes.
>>> >>>>
>>> >>>> --
>>> >>>> Matt Sicker 
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Matt Sicker 
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Matt Sicker 
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> Matt Sicker 
>

remove Chainsaw's site code from git?

[Scott Deboy]

I haven't looked much at the src/site tree of Chainsaw, but it's clear that
the 'real' site code in svn was seeded from Chainsaw's src/site at one
point, but src/site is now stale.

Can I blow that directory away and remove any site-related targets
from Chainsaw's pom?

Thanks,

Scott

Soliciting input: ElasticSearch receiver

[Scott Deboy]

I'm looking at adding an ES receiver and was curious what folks would
like to see when it comes to configuration options/capabilities, other
than the ability to continually retrieve new events on some polling
interval, which I'll make sure to add.

Scott

Re: Bug in latest Chainsaw V2 (date 20.1.2018)

[Scott Deboy]

Nice catch!  Will check it out.

Scott

On 3/15/18, ruch...@gmx.de  wrote:
> Hello,
>
> I just downloaded the latest version and there seems to be a bug when
> importing / displaying log4j xml files:
>
> The line nr. is show in the column 'MILLISDELTA' (see screenshot).
>
> Regards
>
> Marc
>
>
>

Re-enable appbundle-maven-plugin in Chainsaw build

[Scott Deboy]

Hi Matt,

Re: 1123826836323a94d73355f0f6d7fd39466ad657 - Disable macOS packaging step

Looks like you disabled this to get jenkins working?  Has a comment:
"FIXME: make this plugin optional"

Can you re-enable it?  Optional is fine, I test with this all the time.

Thanks,

Scott

Re: Re-enable appbundle-maven-plugin in Chainsaw build

[Scott Deboy]

I don't know how to fix it, but would like to be able to build
DMGs...is there an alternative to reverting this change until we can
figure out how to get both?

On 3/15/18, Matt Sicker  wrote:
> I wasn't able to figure out how to do it. I can't seem to add a build
> plugin inside a profile. Do you know how? I only discovered this issue when
> writing the Jenkinsfile since I build it on macOS locally (and while
> releasing).
>
> On 15 March 2018 at 14:58, Scott Deboy  wrote:
>
>> Hi Matt,
>>
>> Re: 1123826836323a94d73355f0f6d7fd39466ad657 - Disable macOS packaging
>> step
>>
>> Looks like you disabled this to get jenkins working?  Has a comment:
>> "FIXME: make this plugin optional"
>>
>> Can you re-enable it?  Optional is fine, I test with this all the time.
>>
>> Thanks,
>>
>> Scott
>>
>
>
>
> --
> Matt Sicker 
>

Chainsaw update

[Scott Deboy]

Hey all,

Long time.

I decided to work through the pom ugliness and a couple of swing
degradation issues in Chainsaw.

I found an ASL2 Mac dmg creation maven plugin, and it works well on my
Mac, if anyone cares to try it out please do.

Pushing changes to master shortly.

Re: Chainsaw update

[Scott Deboy]

Holy cow. February?

I have zero problem with us nuking the object serialization receiver
support. I think the vfs receiver is the way to go, still works great.

I can remove the code in Chainsaw master.

Hope all are well, good to hear from you!

Scott

On Fri, Nov 6, 2020, 7:53 PM Ralph Goers  wrote:

> Great to hear from you again!  I don’t know if you saw it but there is a
> Chainsaw related email on Feb 12 of this year in the private list that you
> should take a look at if you are planning on doing some work on Chainsaw.
>
> Ralph
>
> > On Nov 6, 2020, at 5:57 PM, Scott Deboy  wrote:
> >
> > Hey all,
> >
> > Long time.
> >
> > I decided to work through the pom ugliness and a couple of swing
> > degradation issues in Chainsaw.
> >
> > I found an ASL2 Mac dmg creation maven plugin, and it works well on my
> > Mac, if anyone cares to try it out please do.
> >
> > Pushing changes to master shortly.
> >
>
>
>

Re: [CI][FAILURE] Logging/chainsaw/master#10 has potential issues

[Scott Deboy]

Updated to version 3 of the parent pom and clean site:site package
runs fine, pushed to master.

On 11/7/20, Matt Sicker  wrote:
> Looks like we need to either fix this pom or the parent pom.
>
> On Fri, Nov 6, 2020 at 21:34 Mr. Jenkins 
> wrote:
>
>> *BUILD FAILURE*
>> Build URL
>> https://ci-builds.apache.org/job/Logging/job/chainsaw/job/master/10/
>> Project: master
>> Date of build: Sat, 07 Nov 2020 03:32:20 +
>> Build duration: 1 min 58 sec and counting
>> * JUnit Tests *
>> Name: org.apache.log4j.chainsaw Failed: 0 test(s), Passed: 1 test(s),
>> Skipped: 0 test(s), Total: 1 test(s)
>> Name: org.apache.log4j.chainsaw.receivers Failed: 0 test(s), Passed: 1
>> test(s), Skipped: 0 test(s), Total: 1 test(s)
>> Name: org.apache.log4j.db Failed: 0 test(s), Passed: 2 test(s), Skipped:
>> 0
>> test(s), Total: 2 test(s)
>> Name: org.apache.log4j.helpers Failed: 0 test(s), Passed: 1 test(s),
>> Skipped: 0 test(s), Total: 1 test(s)
>> Name: org.apache.log4j.rewrite Failed: 0 test(s), Passed: 3 test(s),
>> Skipped: 0 test(s), Total: 3 test(s)
>> Name: org.apache.log4j.xml Failed: 0 test(s), Passed: 4 test(s), Skipped:
>> 0 test(s), Total: 4 test(s)
>> * CONSOLE OUTPUT *
>> [...truncated 3074 lines...]
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/class-use/ShutdownListener.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/class-use/ApplicationPreferenceModelSaver.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/class-use/LoggerNameModelSupport.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/class-use/ColumnComparator.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/class-use/ExpressionRuleContext.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/class-use/LogFilePatternLayoutBuilder.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/class-use/GeneratorBeanInfo.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/version/class-use/VersionManager.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/messages/class-use/MessageCenter.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/ApplicationPreferenceModel.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/SaveSettingsEvent.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/LoadSettingsEvent.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/SettingsEvent.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/SettingsListener.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/ProfileManager.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/SettingsManager.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/Profileable.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/MRUFileList.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/class-use/MRUFileListPreferenceSaver.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/prefs/MRUFileListPreferenceSaver.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/CopyEventsToClipboardAction.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/filter/class-use/EventTypeEntryContainer.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org/apache/log4j/chainsaw/filter/class-use/FilterModel.html
>> longer than 100 characters.
>> [WARNING] Entry:
>> apache-chainsaw-2.1.0-SNAPSHOT/site/apidocs/org

Re: Chainsaw update

[Scott Deboy]

I assume reverse-connect is still fine (SocketHubAppender/Receiver),
as Chainsaw is being configured to reach a specific (assumed trusted)
endpoint, yes?



On 11/6/20, Scott Deboy  wrote:
> Holy cow. February?
>
> I have zero problem with us nuking the object serialization receiver
> support. I think the vfs receiver is the way to go, still works great.
>
> I can remove the code in Chainsaw master.
>
> Hope all are well, good to hear from you!
>
> Scott
>
> On Fri, Nov 6, 2020, 7:53 PM Ralph Goers 
> wrote:
>
>> Great to hear from you again!  I don’t know if you saw it but there is a
>> Chainsaw related email on Feb 12 of this year in the private list that
>> you
>> should take a look at if you are planning on doing some work on Chainsaw.
>>
>> Ralph
>>
>> > On Nov 6, 2020, at 5:57 PM, Scott Deboy  wrote:
>> >
>> > Hey all,
>> >
>> > Long time.
>> >
>> > I decided to work through the pom ugliness and a couple of swing
>> > degradation issues in Chainsaw.
>> >
>> > I found an ASL2 Mac dmg creation maven plugin, and it works well on my
>> > Mac, if anyone cares to try it out please do.
>> >
>> > Pushing changes to master shortly.
>> >
>>
>>
>>
>

Re: Chainsaw update

[Scott Deboy]

Chainsaw supports log4j1 xml format via tcp or local file, and supports
parsing of arbitrary plain text formats via LogFilePatternReceiver (tailing
of log files, including via ssh).

Scott

On Sat, Nov 7, 2020, 11:45 AM Robert Middleton  wrote:

> Would this be a total removal of the Java deserialization?  I ask
> because I think I've used that before with log4cxx to send log
> messages to chainsaw.
>
> Alternatively, I guess the better question is "should chainsaw support
> structured log messages input?"  I know that there was something about
> log4j2 supporting GELF a while ago - perhaps that could be a good
> standard for sending log messages?
>
> -Robert Middleton
>
> On Sat, Nov 7, 2020 at 12:27 PM Matt Sicker  wrote:
> >
> > Any use of deserialization over the network (or from untrusted input
> > sources in general) should use an allowlist of deserializable classes.
> > That's what we did in log4j2's serialized log event receiver code a
> > few years ago, for example:
> > https://github.com/apache/logging-log4j2/commit/5dcc192
> > (CVE-2017-5646).
> >
> > On Sat, 7 Nov 2020 at 11:12, Scott Deboy  wrote:
> > >
> > > I assume reverse-connect is still fine (SocketHubAppender/Receiver),
> > > as Chainsaw is being configured to reach a specific (assumed trusted)
> > > endpoint, yes?
> > >
> > >
> > >
> > > On 11/6/20, Scott Deboy  wrote:
> > > > Holy cow. February?
> > > >
> > > > I have zero problem with us nuking the object serialization receiver
> > > > support. I think the vfs receiver is the way to go, still works
> great.
> > > >
> > > > I can remove the code in Chainsaw master.
> > > >
> > > > Hope all are well, good to hear from you!
> > > >
> > > > Scott
> > > >
> > > > On Fri, Nov 6, 2020, 7:53 PM Ralph Goers  >
> > > > wrote:
> > > >
> > > >> Great to hear from you again!  I don’t know if you saw it but there
> is a
> > > >> Chainsaw related email on Feb 12 of this year in the private list
> that
> > > >> you
> > > >> should take a look at if you are planning on doing some work on
> Chainsaw.
> > > >>
> > > >> Ralph
> > > >>
> > > >> > On Nov 6, 2020, at 5:57 PM, Scott Deboy 
> wrote:
> > > >> >
> > > >> > Hey all,
> > > >> >
> > > >> > Long time.
> > > >> >
> > > >> > I decided to work through the pom ugliness and a couple of swing
> > > >> > degradation issues in Chainsaw.
> > > >> >
> > > >> > I found an ASL2 Mac dmg creation maven plugin, and it works well
> on my
> > > >> > Mac, if anyone cares to try it out please do.
> > > >> >
> > > >> > Pushing changes to master shortly.
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >
>

Re: Chainsaw update

[Scott Deboy]

If I recall correctly, log4cxx supports the log4j xml format over tcp.

Scott

On Sat, Nov 7, 2020, 11:49 AM Matt Sicker  wrote:

> It would limit the supported classes to a safe allowlist. Ideally, we
> should be using both standardized logging formats (including de facto
> standards like GELF) as well as developing a proper binary logging
> format proposed a few years ago.
>
> On Sat, 7 Nov 2020 at 13:45, Robert Middleton  wrote:
> >
> > Would this be a total removal of the Java deserialization?  I ask
> > because I think I've used that before with log4cxx to send log
> > messages to chainsaw.
> >
> > Alternatively, I guess the better question is "should chainsaw support
> > structured log messages input?"  I know that there was something about
> > log4j2 supporting GELF a while ago - perhaps that could be a good
> > standard for sending log messages?
> >
> > -Robert Middleton
> >
> > On Sat, Nov 7, 2020 at 12:27 PM Matt Sicker  wrote:
> > >
> > > Any use of deserialization over the network (or from untrusted input
> > > sources in general) should use an allowlist of deserializable classes.
> > > That's what we did in log4j2's serialized log event receiver code a
> > > few years ago, for example:
> > > https://github.com/apache/logging-log4j2/commit/5dcc192
> > > (CVE-2017-5646).
> > >
> > > On Sat, 7 Nov 2020 at 11:12, Scott Deboy 
> wrote:
> > > >
> > > > I assume reverse-connect is still fine (SocketHubAppender/Receiver),
> > > > as Chainsaw is being configured to reach a specific (assumed trusted)
> > > > endpoint, yes?
> > > >
> > > >
> > > >
> > > > On 11/6/20, Scott Deboy  wrote:
> > > > > Holy cow. February?
> > > > >
> > > > > I have zero problem with us nuking the object serialization
> receiver
> > > > > support. I think the vfs receiver is the way to go, still works
> great.
> > > > >
> > > > > I can remove the code in Chainsaw master.
> > > > >
> > > > > Hope all are well, good to hear from you!
> > > > >
> > > > > Scott
> > > > >
> > > > > On Fri, Nov 6, 2020, 7:53 PM Ralph Goers <
> ralph.go...@dslextreme.com>
> > > > > wrote:
> > > > >
> > > > >> Great to hear from you again!  I don’t know if you saw it but
> there is a
> > > > >> Chainsaw related email on Feb 12 of this year in the private list
> that
> > > > >> you
> > > > >> should take a look at if you are planning on doing some work on
> Chainsaw.
> > > > >>
> > > > >> Ralph
> > > > >>
> > > > >> > On Nov 6, 2020, at 5:57 PM, Scott Deboy 
> wrote:
> > > > >> >
> > > > >> > Hey all,
> > > > >> >
> > > > >> > Long time.
> > > > >> >
> > > > >> > I decided to work through the pom ugliness and a couple of swing
> > > > >> > degradation issues in Chainsaw.
> > > > >> >
> > > > >> > I found an ASL2 Mac dmg creation maven plugin, and it works
> well on my
> > > > >> > Mac, if anyone cares to try it out please do.
> > > > >> >
> > > > >> > Pushing changes to master shortly.
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >
>

Re: [meta] What's been going on with log4net, log4cxx, and chainsaw? Request for reports

[Scott Deboy]

I'll work to get that Chainsaw release out.

On 2/9/21, Davyd McColl  wrote:
> Hi Matt
>
> log4net has been quite quiet over the last quarter, partly because I took a
> break from all things code for a month, and partly because I'm still trying
> to pick up momentum after that break!
>
> However, there has been minor movement at GitHub, and your mail has reminded
> me to get back on track with chipping away at the JIRA board.
>
> -d
> On 2021/02/09 19:40:43, Matt Sicker  wrote:
> Over the past year or two, I've been working to include more details
> in our quarterly board report about what's been going on in the
> community and development. As I'm mostly active in Log4j and some
> adjacent code, I'm not always very informed about the development
> details in log4net, log4cxx, and chainsaw. While I do try to review
> the PRs, emails, and Jira issues that had activity during each
> quarter, as I'm not deep in the weeds of those subprojects, I haven't
> been able to do them justice in our past reports, especially as these
> subprojects experienced new bursts of activity.
>
> Past board reports from this PMC are at [1] which dates back to the
> founding of the project. Interestingly enough, this lack of detailed
> reporting for non-log4j subprojects here has been a theme since
> forever. I'd love to improve on this by emulating what the Apache
> Incubator does by having our subprojects individually report summaries
> of their past quarter to the PMC. Then we can report and publish
> richer and more detailed summaries of what's going on.
>
> We have a board report due this week, so I don't really expect that we
> can fully bootstrap this idea for that one. Our next board report will
> be due in early May 2021, so subproject summaries should be assembled
> by the end of April 2021. Would anyone like to volunteer to shepherd
> or write up summaries for any particular subproject here? We
> particularly need people to help report on the projects mentioned in
> the subject.
>
> [1]: https://whimsy.apache.org/board/minutes/Logging_Services.html
>

Chainsaw build

[Scott Deboy]

I've repaired the Mac UI integration and I think it's time to make a release.

I'm not sure of the process, it's been forever.

'mvn clean site:site package' works fine for me on my Mac, including
DMG creation.

I'd like to get the DMG available to folks for download.

Happy to help,

Thanks,

Scott

Re: [Chainsaw] Minor fixes

[Scott Deboy]

Chainsaw Mac integration leverages java9 features now (Mac prefs menu
integration). I can review merge requests.

On Sat, May 8, 2021, 11:19 AM Matt Sicker  wrote:

> It appears that Chainsaw updated its minimum Java version to 9. I'll
> get that fixed in the Jenkins build. As for committing the repository,
> you are a committer and can do so. We do commit-then-review here which
> allows people to asynchronously review changes with lazy consensus.
>
> On Fri, 7 May 2021 at 21:45, Robert Middleton 
> wrote:
> >
> > I've been doing some messing around with chainsaw the past few days,
> > and I've fixed a few minor issues(and put in some PRs for them) - does
> > somebody(Scott?) want to take a look at them?  I can merge stuff if
> > needed, but I'm not sure if somebody else prefers to take some lead on
> > chainsaw.
> >
> > Side note, the Jenkins build fails for chainsaw at the moment - I'm
> > not sure who takes care of that either.
> >
> > -Robert Middleton
>

Re: [Chainsaw] JSON Support

[Scott Deboy]

Arbitrary text formats are already supported in Chainsaw -files can be
tailed locally or remotely (ssh) via a receiver that leverages Commons
VFS:

https://logging.apache.org/chainsaw/2.x/apidocs/org/apache/log4j/chainsaw/vfs/VFSLogFilePatternReceiver.html

The receiver supports the common pattern layout fields (timestamp,
level, thread, message, etc) and supports custom properties as well.

Example pattern that'll parse a log line:




It also supports the 2-line java.util.logging stuff, as well as custom
level definitions (think Android logcat single-char levels).

Scott

On 6/18/21, Ralph Goers  wrote:
>
>
>> On Jun 18, 2021, at 10:40 AM, Matt Sicker  wrote:
>>
>> A couple other common log collection setups I've come across over time:
>>
>> * Logging to stdout/stderr in a standard format, then use a log
>> collection API from your orchestration engine (common in the
>> Kubernetes world to avoid logging to a file).
>
> NOT recommended for use with Log4j. See
> http://logging.apache.org/log4j/2.x/manual/cloud.html.
>
>> * Logging to a log file as normal, but running a log forwarding agent
>> alongside (e.g., Splunk, Logstash).
>> * Logging to syslog (typically more important for auditing and
>> security related logs)
>>
>> For the log format itself, JSON template layouts work great here for
>> customizing how much info you need in your logs. It also makes it much
>> easier to create log indices in various log searching products. Which
>> particular one hasn't been as important in my experience as trying to
>> stay consistent.
>>
>
> I happen to like GELF as it neatly solves the problem of Java Exceptions
> having newlines in them. Other formats that use the newline to delimit the
> end of the message require weird rules to be set up in Logstash to glue
> the various lines back together again. Invariably some message will violate
>
> the assumptions the rules are based on.
>
> Ralph
>
>
>

Re: [Chainsaw] Removal of Log4j1

[Scott Deboy]

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  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"?>
> 
>   
> 
>   
> 
> 
>   
> 
>   
>   
> 
>   
>   
> 
>   
> 
>
> 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ı  wrote:
>>
>> +1 for implementation-agnostic custom DTO tailored for Chainsaw.
>>
>> On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker  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 
>> > 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
>> > >> 
>> > 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

[Scott Deboy]

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  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 
> 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 
>> 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  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"?>
>> > > 
>> > >   
>> > > 
>> > >   
>> > > 
>> > > 
>> > >   
>> > > 
>> > >   
>> > >   
>> > > 
>> > >   
>> > >   
>> > > 
>> > >   
>> > > 
>> > >
>> > > 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ı  wrote:
>> > >>
>> > >> +1 for implementation-agnostic custom DTO tailored for C

Re: Chainsaw in git

[Scott Deboy]

File a bug and it would get attention.

Also: contributions welcome!

Scott

On May 30, 2017 6:48 PM, "Robert Middleton"  wrote:

> Is chainsaw used/maintained regularly?  There haven't been commits in
> a few years it looks like(also it's not in JIRA for bug tracking, the
> POM indicates that it should be in bugzilla but it doesn't look like
> it's there).
>
> -Robert Middleton
>
> On Tue, May 30, 2017 at 8:27 PM, Remko Popma 
> wrote:
> > Thanks for doing this work, Ralph!
> > Remko
> >
> > (Shameless plug) Every java main() method deserves http://picocli.info
> >
> >> On May 31, 2017, at 8:54, Ralph Goers 
> wrote:
> >>
> >> At the request of Scott Deboy I have migrated chainsaw to git. You can
> view it at https://github.com/apache/logging-chainsaw <
> https://github.com/apache/logging-chainsaw> and check it out from
> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git <
> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git>. Please
> review it and let me know of any problems. If there aren’t any I will
> request infra close down the chainsaw svn repo.
> >>
> >> Ralph
>

Re: Attempting to change consumers of Log4j 2 SerializedLayout

[Scott Deboy]

Chainsaw supports log4j1's xml format over UDP and TCP, as well as any
regular text format via (VFS)LogFilePatternReceiver.  It also supports
log4j1's serialized loggingevent format.

Chainsaw integration with Logj42 is via VFSLogFilePatternReceiver -
you have to specify the pattern and an accessible endpoint.

Scott

On 6/30/17, Matt Sicker  wrote:
> The JMS appender supported it by default, so any configurations set up to
> append to JMS and read them elsewhere as objects won't work by default
> anymore, though that's somewhat a custom config more so than an
> application.
>
> On 30 June 2017 at 08:56, Mikael Ståldal  wrote:
>
>> Now when we have deprecated SerializedLayout, we should attempt to get
>> all
>> known consumers of it to be changed to instead/also support JsonLayout
>> (or
>> something else if more appropriate).
>>
>> The Socket Server in Log4j already support JsonLayout and XmlLayout as
>> well, and I have just changed it to use JsonLayout by default.
>>
>> I have just notified Jörn Huxhorn about Lilith.
>>
>> What about Chainsaw? Does it read Log4j 2 SerializedLayout? Does it
>> support something else as well?
>>
>> What about Flume?
>>
>> Logback Beagle seems to be Logback specific, so we don't need to worry
>> about it. https://github.com/qos-ch/logback-beagle
>>
>> Do we know of any other?
>>
>
>
>
> --
> Matt Sicker 
>

Re: Retire Chainsaw

[Scott Deboy]

Well, it still works well, and real time log analysis and Chainsaw's
support for filtering are very powerful for many dev-local use cases.

User base I can't speak to, but I agree based on lack of questions it's
probably very low to non-existent.

I'd prefer we find an option that isn't "nuke it from orbit".

Scott



On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı  wrote:

> AFAIC, Chainsaw is hardly getting any maintenance. Considering its activity
> over the years, I haven't witnessed a user base either. I suppose the trend
> in processing logs (i.e., rendering them into JSON and storing them in
> Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from
> `PatternLayout`-rendered files collected under `/var/logs`. I would like to
> retire[1] Chainsaw in a vote thread. Thoughts?
>
> [1] Retirement translates to archival of the repository and clearing up its
> mentions in `logging.apache.org`.
>

Re: Retire Chainsaw

[Scott Deboy]

Ralph,

I already removed the socket appender vulnerability. I believe that was the
only one.

Scott

On Tue, Sep 19, 2023, 11:10 AM Ralph Goers 
wrote:

> Scott,
>
> Apparently Chainsaw has dependencies that have CVEs reported against them
> (or so I am told). We haven’t enabled GitHub Issues for Chainsaw AFAIK.
> Both of these need to be addressed if the project is going to be considered
> active.  Are you willing to help with both of these?
>
> Ralph
>
> > On Sep 19, 2023, at 3:25 AM, Scott Deboy  wrote:
> >
> > Well, it still works well, and real time log analysis and Chainsaw's
> > support for filtering are very powerful for many dev-local use cases.
> >
> > User base I can't speak to, but I agree based on lack of questions it's
> > probably very low to non-existent.
> >
> > I'd prefer we find an option that isn't "nuke it from orbit".
> >
> > Scott
> >
> >
> >
> > On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı  wrote:
> >
> >> AFAIC, Chainsaw is hardly getting any maintenance. Considering its
> activity
> >> over the years, I haven't witnessed a user base either. I suppose the
> trend
> >> in processing logs (i.e., rendering them into JSON and storing them in
> >> Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from
> >> `PatternLayout`-rendered files collected under `/var/logs`. I would
> like to
> >> retire[1] Chainsaw in a vote thread. Thoughts?
> >>
> >> [1] Retirement translates to archival of the repository and clearing up
> its
> >> mentions in `logging.apache.org`.
> >>
>
>

Re: Retire Chainsaw

[Scott Deboy]

Ralph,

I didn't misunderstand.

Scott

On Tue, Sep 19, 2023, 12:30 PM Ralph Goers 
wrote:

> Scott,
>
> I think you misunderstood. I wasn’t referring to any CVEs in Chainsaw code
> but in dependencies Chainsaw uses. Users expect dependencies to be updated
> periodically so that they can build a project that passes all their
> security scans.
>
> Ralph
>
> > On Sep 19, 2023, at 11:26 AM, Scott Deboy  wrote:
> >
> > Ralph,
> >
> > I already removed the socket appender vulnerability. I believe that was
> the
> > only one.
> >
> > Scott
> >
> > On Tue, Sep 19, 2023, 11:10 AM Ralph Goers 
> > wrote:
> >
> >> Scott,
> >>
> >> Apparently Chainsaw has dependencies that have CVEs reported against
> them
> >> (or so I am told). We haven’t enabled GitHub Issues for Chainsaw AFAIK.
> >> Both of these need to be addressed if the project is going to be
> considered
> >> active.  Are you willing to help with both of these?
> >>
> >> Ralph
> >>
> >>> On Sep 19, 2023, at 3:25 AM, Scott Deboy 
> wrote:
> >>>
> >>> Well, it still works well, and real time log analysis and Chainsaw's
> >>> support for filtering are very powerful for many dev-local use cases.
> >>>
> >>> User base I can't speak to, but I agree based on lack of questions it's
> >>> probably very low to non-existent.
> >>>
> >>> I'd prefer we find an option that isn't "nuke it from orbit".
> >>>
> >>> Scott
> >>>
> >>>
> >>>
> >>> On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı  wrote:
> >>>
> >>>> AFAIC, Chainsaw is hardly getting any maintenance. Considering its
> >> activity
> >>>> over the years, I haven't witnessed a user base either. I suppose the
> >> trend
> >>>> in processing logs (i.e., rendering them into JSON and storing them in
> >>>> Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from
> >>>> `PatternLayout`-rendered files collected under `/var/logs`. I would
> >> like to
> >>>> retire[1] Chainsaw in a vote thread. Thoughts?
> >>>>
> >>>> [1] Retirement translates to archival of the repository and clearing
> up
> >> its
> >>>> mentions in `logging.apache.org`.
> >>>>
> >>
> >>
>
>

Re: [VOTE] Move Chainsaw to dormant status

[Scott Deboy]

-1

While changes may be infrequent, the project is still useful and works
well. I'll continue to contribute to maintenance.

Scott

On Thu, Sep 21, 2023, 10:00 AM Volkan Yazıcı  wrote:

> As earlier discussions[1] indicate, Chainsaw has been lacking on
> maintenance and no PMC member stepped up to perform necessary chores.
> This is a vote to retire the Chainsaw by means of
>
> - Move it to the list of dormant projects[2]
> - Making it clear in its README and website that the project is not
> maintained anymore
> - Archive its repository[3]
>
> Please cast your votes on this mailing list.
>
> [ ] +1, retire the project
> [ ] -1, don't retire, because...
>
> This vote is open for 72 hours and will pass unless getting a net
> negative vote count. All votes are welcome and we encourage everyone,
> but only the Logging Services PMC votes are officially counted. At
> least 3 +1 votes and more positive than negative votes are required.
>
> [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
> [2] https://logging.apache.org/dormant.html
> [3] https://github.com/apache/chainsaw
>

Re: [VOTE] Move Chainsaw to dormant status

[Scott Deboy]

Most of the ui elements can be hidden. The explicit hidden expression
filter and real time update support are indispensable.

I use it to aggregate results from multiple hosts into a single tab and
filter in that view.

Scott



On Fri, Sep 22, 2023, 7:35 PM Robert Middleton 
wrote:

> I think Chainsaw /can/ be useful, but it currently is not.  If people are
> willing to work on it a bit more, I can help out a bit.  I can see it
> potentially being useful for the type of work that I do(embedded work) but
> it needs a fair amount of attention in order to get to the useful level
> IMO.
>
> I have spent a fair amount of time getting it into a state where it will
> run with newer JVMs and removing the old dependencies and re-architecting
> the backend to be more generic and allow for inputs from all types of
> sources.  I think the basic architecture is sound at this point, but I
> think the GUI is much too busy to make it useful.  I have been thinking
> about how it could be re-done though, I do have some ideas that I can put
> in a new thread.
>
> Latest staging site for reference:
> https://logging.staged.apache.org/chainsaw/2.2.0/
>
> -Robert Middleton
>
> On Fri, Sep 22, 2023 at 10:30 AM Scott Deboy 
> wrote:
>
> > -1
> >
> > While changes may be infrequent, the project is still useful and works
> > well. I'll continue to contribute to maintenance.
> >
> > Scott
> >
> > On Thu, Sep 21, 2023, 10:00 AM Volkan Yazıcı  wrote:
> >
> > > As earlier discussions[1] indicate, Chainsaw has been lacking on
> > > maintenance and no PMC member stepped up to perform necessary chores.
> > > This is a vote to retire the Chainsaw by means of
> > >
> > > - Move it to the list of dormant projects[2]
> > > - Making it clear in its README and website that the project is not
> > > maintained anymore
> > > - Archive its repository[3]
> > >
> > > Please cast your votes on this mailing list.
> > >
> > > [ ] +1, retire the project
> > > [ ] -1, don't retire, because...
> > >
> > > This vote is open for 72 hours and will pass unless getting a net
> > > negative vote count. All votes are welcome and we encourage everyone,
> > > but only the Logging Services PMC votes are officially counted. At
> > > least 3 +1 votes and more positive than negative votes are required.
> > >
> > > [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
> > > [2] https://logging.apache.org/dormant.html
> > > [3] https://github.com/apache/chainsaw
> > >
> >
>

Re: [Chainsaw] Thoughts on moving forward

[Scott Deboy]

Please review the various display setting controls. Most of what you
mention can be toggled from visible to hidden.

VfsLogFilePatternReceiver does exactly what you're describing. Allowing
live remote tailing of logs over an ssh accessible path.

You control if these logs end up in separate tabs or the same tab via the
routing expression in preferences.

We should slack sometime so I can go over the main features and what was
nuked in the log4j1 removal path and what of those are worth restoring.

Scott

On Sat, Sep 23, 2023, 6:08 PM Robert Middleton 
wrote:

> Since Scott has said that he would help with maintenance and Rob T has also
> indicated that he would perhaps help, this is my view of the current status
> of Chainsaw and what I feel its current deficiencies are.
>
> Current status: Master builds and mostly works.  The last thing that I had
> been working on was updating the config files in order to remove xstream
> and better standardize on using commons configuration.  I think some of the
> configuration settings don't save/load correctly, but some do.  All of
> log4j1 has been removed.  Certain features have been removed too that were
> largely dependent on log4j1.
>
> What I feel would be useful for Chainsaw: For me, I do a lot of embedded
> work.  Most of the log files that we have at my current job just go to
> syslog on our device(syslog is provided by busybox).  So viewing logs is a
> matter of SSHing into the system and just reading from the buffer.  Having
> a utility running on a separate computer that lets me see the
> logs(especially if it can connect automatically to a device) could be very
> useful.  Specific potential use-case: at my last job, I wrote a quick log
> viewing utility that would correlate log messages between two separate
> devices.  This was needed because one device was embedded that logged out
> the serial port, the other was Linux and would log over the network, but
> neither had reliable time.
>
> Current limitations that I find with Chainsaw: The current GUI is not very
> useful.  A large portion of the screen is taken up by toolbars/context
> information that I generally don't find useful.  I think most of the
> features that are in the GUI are very useful(for example, being able to
> trace messages and add matches) but is limited by the fact that I only see
> a small portion of the context at a time.  In my mind, an ideal solution
> would be to get rid of the toolbars as much as possible and to focus more
> on the log messages like you would see in a terminal, but still having the
> capability to right-click on a message/message components and investigate
> individual messages or flag them appropriately.
>
> Perhaps the best way to organize this would be to have a logical split in
> the code: the backend(which receives and routes log messages) and the
> front-end portion.  The front-end could be something like Swing for a GUI,
> or some sort of command-line interface like ncurses.
>
> Thoughts?  What is something that people want to see/think could be
> useful/would want to try and code up?
>
> -Robert Middleton
>

Re: [Chainsaw] Thoughts on moving forward

[Scott Deboy]

Your screenshot didn't come through.

My mental model is usually:

* Hide logs from packages you know aren't relevant  - the tree-based
(package-level) filtering and focus-on actions in the tree are super
helpful for doing that quickly
* Once you've filtered the view down to the set of packages that may be
relevant, hide logs that are getting in the way - via the 'always hide'
expression box, available at the bottom of the tree view
* Use filter expressions to further narrow results
* Annotate those filtered results (the 'marker' column is editable)
* Clear the filter and search the remaining results, annotating if needed
* Optionally save off the logs and share with other devs (they can import
your filtered logs)

All of this and a lot more is possible with the existing set of features.

UI-wise I agree, less is more most of the time. You don't need to parse the
logs, you can put the entire log line in the 'msg' field, but that prevents
you from using some expression support facilitated by the parsing, such
as "level > INFO" or "exception exists".

On Mon, Sep 25, 2023 at 7:28 PM Robert Middleton 
wrote:

> I do know that there are a bunch of settings to hide things that aren't
> useful, I'm just saying that even hiding things I still don't find it super
> useful.  The table view that exists is theoretically useful, but I find
> that it likes to cut off information because it is, well, a table.
>
> The VfsLogFilePatternReceiver I have never gotten to work properly.  I
> think it's good and needed, but it definitely needs a user-friendly way of
> selecting a log file and viewing a live example of how it will parse the
> log file.  Although for my purposes, we don't actually write to a log file,
> so it's a bit of a moot point.
>
> The next question of course is what do I feel would be better?  I spent
> some time working on that tonight as a proof of concept, and here's what I
> came up with(with chainsaw in the background for reference):
> [image: Screenshot from 2023-09-25 22-12-07.png]
>
> Note: this picture is from my VM, so it's definitely squashed since it was
> running at a weird resolution so I could take the screenshot.  But this
> shows a good point: in this screenshot, only about 60% of the UI is
> actually used to view logs.  From the top there's the GNOME title bar,
> title bar, file menu bar, toolbar, tabs, search bar, column headers, and
> then we finally get to what chainsaw is supposed to do - display logs.
>
> What I've done is intentionally a proof of concept at the moment, but it
> provides a much simpler view.  Think of it like viewing logs on the
> terminal, but adding in the capability to do more advanced operations(e.g.
> what chainsaw does with the right-click context menu).  The GUI is at the
> moment just a JTextPane instead of a table, so that fields do not get cut
> off(like they currently do in the table) and it can better scroll like a
> real terminal when new messages come in.  Right-clicking will open up a
> pop-up menu contextually depending on what it is you have clicked on(the
> time, logger name, level, or the message).
>
> Anyway, that's what I personally feel would be more useful, but I would
> love to hear some other ideas.
>
> -Robert Middleton
>
> On Sat, Sep 23, 2023 at 11:35 PM Scott Deboy 
> wrote:
>
>> Please review the various display setting controls. Most of what you
>> mention can be toggled from visible to hidden.
>>
>> VfsLogFilePatternReceiver does exactly what you're describing. Allowing
>> live remote tailing of logs over an ssh accessible path.
>>
>> You control if these logs end up in separate tabs or the same tab via the
>> routing expression in preferences.
>>
>> We should slack sometime so I can go over the main features and what was
>> nuked in the log4j1 removal path and what of those are worth restoring.
>>
>> Scott
>>
>> On Sat, Sep 23, 2023, 6:08 PM Robert Middleton 
>> wrote:
>>
>> > Since Scott has said that he would help with maintenance and Rob T has
>> also
>> > indicated that he would perhaps help, this is my view of the current
>> status
>> > of Chainsaw and what I feel its current deficiencies are.
>> >
>> > Current status: Master builds and mostly works.  The last thing that I
>> had
>> > been working on was updating the config files in order to remove xstream
>> > and better standardize on using commons configuration.  I think some of
>> the
>> > configuration settings don't save/load correctly, but some do.  All of
>> > log4j1 has been removed.  Certain features h

Re: [Chainsaw] Thoughts on moving forward

[Scott Deboy]

Here's how it looks if you hide the tree - note the search results are at
the bottom. If you're not searching, that search area is hidden as well.

Because it's parsing the log, you can filter on logger, level, the message
- any field resolved during parsing.

The annotated lines show up as green by default.

The UI supports multiple tabs (log sources) and will live tail for you as
well.

Note the search results show up as blue in the log panel, and the gutter on
the right displays the individual line colors (black is a search match).



On Mon, Sep 25, 2023 at 8:46 PM Scott Deboy  wrote:

> Your screenshot didn't come through.
>
> My mental model is usually:
>
> * Hide logs from packages you know aren't relevant  - the tree-based
> (package-level) filtering and focus-on actions in the tree are super
> helpful for doing that quickly
> * Once you've filtered the view down to the set of packages that may be
> relevant, hide logs that are getting in the way - via the 'always hide'
> expression box, available at the bottom of the tree view
> * Use filter expressions to further narrow results
> * Annotate those filtered results (the 'marker' column is editable)
> * Clear the filter and search the remaining results, annotating if needed
> * Optionally save off the logs and share with other devs (they can import
> your filtered logs)
>
> All of this and a lot more is possible with the existing set of features.
>
> UI-wise I agree, less is more most of the time. You don't need to parse
> the logs, you can put the entire log line in the 'msg' field, but that
> prevents you from using some expression support facilitated by the parsing,
> such as "level > INFO" or "exception exists".
>
> On Mon, Sep 25, 2023 at 7:28 PM Robert Middleton 
> wrote:
>
>> I do know that there are a bunch of settings to hide things that aren't
>> useful, I'm just saying that even hiding things I still don't find it super
>> useful.  The table view that exists is theoretically useful, but I find
>> that it likes to cut off information because it is, well, a table.
>>
>> The VfsLogFilePatternReceiver I have never gotten to work properly.  I
>> think it's good and needed, but it definitely needs a user-friendly way of
>> selecting a log file and viewing a live example of how it will parse the
>> log file.  Although for my purposes, we don't actually write to a log file,
>> so it's a bit of a moot point.
>>
>> The next question of course is what do I feel would be better?  I spent
>> some time working on that tonight as a proof of concept, and here's what I
>> came up with(with chainsaw in the background for reference):
>> [image: Screenshot from 2023-09-25 22-12-07.png]
>>
>> Note: this picture is from my VM, so it's definitely squashed since it
>> was running at a weird resolution so I could take the screenshot.  But this
>> shows a good point: in this screenshot, only about 60% of the UI is
>> actually used to view logs.  From the top there's the GNOME title bar,
>> title bar, file menu bar, toolbar, tabs, search bar, column headers, and
>> then we finally get to what chainsaw is supposed to do - display logs.
>>
>> What I've done is intentionally a proof of concept at the moment, but it
>> provides a much simpler view.  Think of it like viewing logs on the
>> terminal, but adding in the capability to do more advanced operations(e.g.
>> what chainsaw does with the right-click context menu).  The GUI is at the
>> moment just a JTextPane instead of a table, so that fields do not get cut
>> off(like they currently do in the table) and it can better scroll like a
>> real terminal when new messages come in.  Right-clicking will open up a
>> pop-up menu contextually depending on what it is you have clicked on(the
>> time, logger name, level, or the message).
>>
>> Anyway, that's what I personally feel would be more useful, but I would
>> love to hear some other ideas.
>>
>> -Robert Middleton
>>
>> On Sat, Sep 23, 2023 at 11:35 PM Scott Deboy 
>> wrote:
>>
>>> Please review the various display setting controls. Most of what you
>>> mention can be toggled from visible to hidden.
>>>
>>> VfsLogFilePatternReceiver does exactly what you're describing. Allowing
>>> live remote tailing of logs over an ssh accessible path.
>>>
>>> You control if these logs end up in separate tabs or the same tab via the
>>> routing expression in preferences.
>>>
>>> We should slack sometime so I can go over the main fe

Re: [chainsaw] Trouble starting it at all

[Scott Deboy]

There should be a default config. Do you have anything in the .chainsaw
directory? If so, delete it.

On Fri, Sep 29, 2023, 9:49 AM Christian Grobmeier 
wrote:

> OK, got it running, after commenting those lines:
>
> //statusBar.setSelected(config.getBoolean("statusBar"));
> statusBar.setSelected(false);
> //receivers.setSelected(config.getBoolean("showReceivers"));
> receivers.setSelected(false);
> //toolBar.setSelected(config.getBoolean("toolbar"));
> toolBar.setSelected(false);
> //configureTabPlacement(config.getInt("tabPlacement"));
> configureTabPlacement(1);
>
> Looks like the missing configuration is a problem.
> Is there any configuration I should add to the startup?
>
>
> On Fri, Sep 29, 2023, at 18:36, Christian Grobmeier wrote:
> > I have installed Netbeans and tried it with that.
> > I also tried Corretta 11, Zulu 11, Zulu 11 with FX. OpenJDK 11 is no
> > longer available for me (on Mac) it seems.
> >
> > Still no success. The splash opens, but no further movement.
> >
> > I have two errors earlier, but I don't think they break anything:
> >
> > ERROR org.apache.log4j.chainsaw.LogUI - Uncaught exception in thread
> > Thread[AWT-EventQueue-0,6,main]
> > java.util.NoSuchElementException: Key 'statusBar' does not map to an
> > existing object!
> >   at
> >
> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>
> > ~[commons-configuration2-2.7.jar:2.7]
> >   at
> >
> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>
> > ~[commons-configuration2-2.7.jar:2.7]
> >
> > and the underlying cause is printed extra:
> >
> > java.util.NoSuchElementException: Key 'statusBar' does not map to an
> > existing object!
> >   at
> >
> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
> >   at
> >
> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
> >
> >
> > Either it is something special in the OpenJDK or maybe even related to
> > the Mac. I assume you are on Windows. Could you try with another JDK,
> > maybe Zulu or Correta?
> >
> >
> >
> >
> >
> > --
> > The Apache Software Foundation
> > V.P., Data Privacy
> >
> > On Fri, Sep 29, 2023, at 17:19, Robert Middleton wrote:
> >> It starts up for me with Netbeans and OpenJDK 11.  I would expect an
> >> exception/stack trace to be printed to stderr if an exception was thrown
> >> that caused it to fail to load.
> >>
> >> -Robert Middleton
> >>
> >> On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier <
> grobme...@apache.org>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I have found out Chainsaw requires Java 11. I used this from IntelliJ
> and
> >>> run LogUI.
> >>> However, even when there is no error message, the Splash Screen never
> >>> disappears.
> >>> Is there any specific verion of Java I need?
> >>>
> >>> These are he last lines i see:
> >>>
> >>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
> >>> org.apache.log4j.chainsaw.LogUI
> >>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel
> >>> 15:15:29.581 [AWT-EventQueue-0] DEBUG
> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
> >>> org.apache.log4j.chainsaw.LoggerNameTreePanel
> >>>
> >>> Then no further actitivty,
> >>>
> >>> Any ideas?
> >>>
> >>> --
> >>> The Apache Software Foundation
> >>> V.P., Data Privacy
> >>>
>

Re: [chainsaw] Is ZeroConf support relevant?

[Scott Deboy]

This is a log4j2 feature.

Scott

On Fri, Sep 29, 2023, 12:24 PM Christian Grobmeier 
wrote:

> Volkan asked this question here:
> https://github.com/apache/logging-chainsaw/issues/24
>
> I guess, since Log4j1 is EOL we can safely remove this feature, right?
>

Re: [chainsaw] Lots of commented code // Backwards compatibility?

[Scott Deboy]

I think Robert commented out most of that to get rid of the log4j1
dependency. I'm slightly concerned we'll lose a ton of UI
functionality in that process, but it's in history if it's still
needed, so delete away if you'd like.

For comparison, you can look at the 'chainsaw-with-log4j1-dep' branch.

Scott

On 9/29/23, Christian Grobmeier  wrote:
> Hi,
>
> Looking through the code base, I saw lots of code that is commented. Some
> classes (maybe because of this) are not even used anymore. I only saw one
> class (ChainsawViewer), which might make sense to keep.
>
> Is it OK to remove this all? Or is there a specific reason for this?
>
> Some methods are no longer used or empty despite not being commented. I
> would also like to remove them when they don't have any purpose. Since they
> are public, BC is no longer guaranteed. For a Standalone app like this, I
> don't consider this a problem, but I would like to know if there are any
> objections.
>
> Kind regards,
> Christian
>
>

Re: Refining product feature set strategy

[Scott Deboy]

+1 to everything Ralph said.

On Fri, Sep 29, 2023, 3:53 PM Ralph Goers 
wrote:

> I’m sorry, I can’t really agree with much of any of this. Following the
> thoughts being proposed in this thread much of Log4j 2 and even the initial
> work I did to create it would not have seen the light of day. Almost 100%
> of the stuff Matt has done would never have happened.
>
> It is a fact that people come and go from projects. Some stay longer than
> others. We have had PMC members who disappeared the day after they were
> elected to the PMC. Remko arguably made two of the most significant
> contributions in the GC-Free and Async work. Yet he has largely gone
> inactive. It happens. Even after accepting the JsonTemplateLayout and
> Volkan as a committer we had no guarantee he would stick around. We hoped
> he would and he did. Gary and I have each contributed a large number of
> components because they met some need we have/had and we continue to
> support them.
>
> Requiring hoops that must be jumped through before stuff can be accepted
> is just a terrible idea. It does nothing but create a perception that we
> are not open to new contributions and new contributors.
>
> Yes, we can retire things. I don’t think anyone is arguing against
> retiring log4j-cassandra. I haven’t seen any arguments against log4j-kafka.
> That is primarily because they are woefully out of date. However, there is
> nothing wrong with a module that hasn’t had any updates in a long while if
> it is meeting user’s needs. You are never going to know for certain home
> many users there are of a given module. That data is impossible to get. Any
> company that has their own repository manager (which should be most) will
> download a release of an artifact from Maven Central once and it will be
> hard for you to know when they did it. The metrics Sonatype provided came
> from their security product, which not everyone purchases. Yes, you can
> make guesses from those numbers but you can’t actually know how good those
> guesses are.
>
> In short, I am in favor of retiring things when they are no longer
> maintainable.  I am completely in favor of adding new components when they
> make sense. IOW, every contribution needs to be considered on its own
> merits.
>
> Ralph
>
>
>
> > On Sep 29, 2023, at 11:32 AM, Gary Gregory 
> wrote:
> >
> > I think Jira is good enough for that, since there is transition from
> state
> > to state that can be used to shepherd issues through. RFC, JEP, all way
> too
> > heavy handed for us IMO.
> >
> > Gary
> >
> >
> > On Fri, Sep 29, 2023, 2:05 PM Matt Sicker  wrote:
> >
> >> I think it could be valuable for us to establish some form of an RFC
> >> process for proposing and developing major new features. I also want to
> >> avoid being too process-heavy here as that would also disincentivize
> >> contributions. I agree that we should try to be more data-driven to
> >> determine what features and products should have the most attention.
> >>
> >> I do like the idea of having “sample” plugins which are not distributed
> as
> >> binaries, though, which can be used in documentation for examples of
> how to
> >> integrate your own systems. With the flexibility of the plugin system
> here,
> >> we can defer the implementation of more obscure integrations to the end
> >> user.
> >>
> >> I will note that we do already have some level of filtering to what we
> >> include. I’ve proposed numerous features in the past that I didn’t
> pursue
> >> due to reasons raised by others or lack of interest.
> >>
> >>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı  wrote:
> >>>
> >>> I want to challenge the current way of PMC determining the product
> >> feature
> >>> set and work towards a more sustainable alternative.
> >>>
> >>> Logging Services team...
> >>>
> >>>  - delivers mission-critical products that are deployed at the core of
> >>>  the world-wide infrastructure (actually, in Mars too)
> >>>  - is short on development resources compared to its wide range of
> >>>  offerings
> >>>  - deals with substantial amount of legacy
> >>>  - suffers from knowledge silo
> >>>
> >>> Any IT team in this state would be really conservative on accepting new
> >>> features and try hard to get rid of the bloat. They would react to this
> >>> challenge by first discovering the user base, pinpointing the core
> >> values,
> >>> and then lazer-focusing the limited development resources on to the
> >> crucial
> >>> deliverables. Though we do something totally different, one can even
> say
> >>> the opposite. Below I share excerpts from recent mailing list posts.
> >>>
> >>> *"I had added [X] ... to show how to write plugins and for some
> >>> consulting-related use cases"* – PMC member explaining how feature X
> was
> >>> released
> >>>
> >>> *"... stuff seems like it could be useful"* – PMC member asking to keep
> >>> feature X
> >>>
> >>> *"my employer used [X] ... for anyone implementing ... this would be
> very
> >>> relevant.  By archiving this we are

Re: [chainsaw] What is necessary for a 2.2 release?

[Scott Deboy]

It's great to see the contribution, thanks Christian!

I pulled down latest master and it looks like there are some UI
glitches we should fix - for example, resizing the logger tree pane
doesn't render correctly.

As I mentioned before, I assume there are a bunch of features we lost
when we moved from log4j1 - some may not be critical, but I think
persisting 'default' tab settings is pretty important if it's not

I'd like us to at least support the log4j2 zeroconf functionality as
well as VFSLogFilePatternReceiver.

I'm happy to dig in - will look at latest master and contribute.

Scott

On 10/1/23, Christian Grobmeier  wrote:
> Hello,
>
> I am moving things around a lot. There is much refactoring that is necessary
> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs is so
> complicated to understand that it prevents people from contributing - let
> alone Swing, but we can't change that.
>
> Apart from usual refactorings, I wonder what should be the goal of 2.2?
>
> I have already upgraded some dependencies that have security flaws. 2 more
> are in the pom, but they have no patched versions so far.
>
> Should we add at least one feature? Is there maybe one already in that I
> missed?
>
> I would appreciate it if one of the more experienced Swing-devs here could
> advise or maybe contribute some code so we can justify a release.
>
> The next question would be:
> How is chainsaw released at all?
>
> Kind regards,
> Christian
>

Re: [chainsaw] What is necessary for a 2.2 release?

[Scott Deboy]

We lost the initial 'Load Chainsaw Configuration' dialog (and menu
item) that gave folks a way to set up a Chainsaw configuration. I'd
like to see us restore that functionality, along with a menu support.

Right now, you have to define a receiver by hand, and it has to be
redefined on each app startup because it's not saved.

The ability to create a Receiver config from a fileappender definition
would help the user experience - that was one of the 'load chainsaw
config' features, but may have been specific to log4j1 appender config
files. That'd be a great log4j2-supporting feature.

Scott



On 10/1/23, Scott Deboy  wrote:
> It's great to see the contribution, thanks Christian!
>
> I pulled down latest master and it looks like there are some UI
> glitches we should fix - for example, resizing the logger tree pane
> doesn't render correctly.
>
> As I mentioned before, I assume there are a bunch of features we lost
> when we moved from log4j1 - some may not be critical, but I think
> persisting 'default' tab settings is pretty important if it's not
>
> I'd like us to at least support the log4j2 zeroconf functionality as
> well as VFSLogFilePatternReceiver.
>
> I'm happy to dig in - will look at latest master and contribute.
>
> Scott
>
> On 10/1/23, Christian Grobmeier  wrote:
>> Hello,
>>
>> I am moving things around a lot. There is much refactoring that is
>> necessary
>> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs is so
>> complicated to understand that it prevents people from contributing - let
>> alone Swing, but we can't change that.
>>
>> Apart from usual refactorings, I wonder what should be the goal of 2.2?
>>
>> I have already upgraded some dependencies that have security flaws. 2
>> more
>> are in the pom, but they have no patched versions so far.
>>
>> Should we add at least one feature? Is there maybe one already in that I
>> missed?
>>
>> I would appreciate it if one of the more experienced Swing-devs here
>> could
>> advise or maybe contribute some code so we can justify a release.
>>
>> The next question would be:
>> How is chainsaw released at all?
>>
>> Kind regards,
>> Christian
>>
>

Re: [chainsaw] What is necessary for a 2.2 release?

[Scott Deboy]

The ability to route events to tabs is a core feature in the code -
that's how Chainsaw log messages end up in a Chainsaw-specific tab -
but the ability to control that routing via a 'routing expression' was
nuked from app-wide preferences - another thing we should bring back.

It looks like we lost a lot of prefs, both panel-level and app-wide prefs.

Scott

On 10/1/23, Robert Middleton  wrote:
> I would say the saving/loading of settings is probably the main thing to
> fix - if I remember correctly, it kinda works at the moment.  Part of the
> issue with what it did before was that the settings were scattered among
> several different files with no apparent rhyme or reason, and converting
> them to one file I'm not sure if everything works.
>
> The one feature that I'm pretty sure doesn't exist is the ability to have
> multiple log messages go to one tab, but I don't think that is critical for
> release.  In order to properly support that I think requires a bit more
> planning on both the UI side(so you can know how things are routed) and on
> the back-end side(to do the actual routing).
>
> -Robert Middleton
>
> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier 
> wrote:
>
>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote:
>> > It's great to see the contribution, thanks Christian!
>> >
>> > I pulled down latest master and it looks like there are some UI
>> > glitches we should fix - for example, resizing the logger tree pane
>> > doesn't render correctly.
>> >
>> > As I mentioned before, I assume there are a bunch of features we lost
>> > when we moved from log4j1 - some may not be critical, but I think
>> > persisting 'default' tab settings is pretty important if it's not
>> >
>> > I'd like us to at least support the log4j2 zeroconf functionality as
>> > well as VFSLogFilePatternReceiver.
>> >
>> > I'm happy to dig in - will look at latest master and contribute.
>>
>> I would be more than glad if you could take some kind of a lead here. My
>> Swing-foo is long time gone and so far I just tried to clean a few things
>> or make the code more comprehensible.
>>
>> I will keep trying to extracting things, making classes a bit smaller if
>> possible. I will closely follow what you are doing and try to learn from
>> it.
>>
>> Maybe, once we can persist tab settings and then release it, no matter
>> how
>> the rest of the cleanup is.
>>
>>
>> >
>> > Scott
>> >
>> > On 10/1/23, Christian Grobmeier  wrote:
>> >> Hello,
>> >>
>> >> I am moving things around a lot. There is much refactoring that is
>> necessary
>> >> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs is
>> >> so
>> >> complicated to understand that it prevents people from contributing -
>> let
>> >> alone Swing, but we can't change that.
>> >>
>> >> Apart from usual refactorings, I wonder what should be the goal of
>> >> 2.2?
>> >>
>> >> I have already upgraded some dependencies that have security flaws. 2
>> more
>> >> are in the pom, but they have no patched versions so far.
>> >>
>> >> Should we add at least one feature? Is there maybe one already in that
>> >> I
>> >> missed?
>> >>
>> >> I would appreciate it if one of the more experienced Swing-devs here
>> could
>> >> advise or maybe contribute some code so we can justify a release.
>> >>
>> >> The next question would be:
>> >> How is chainsaw released at all?
>> >>
>> >> Kind regards,
>> >> Christian
>> >>
>>
>

Re: [chainsaw] What is necessary for a 2.2 release?

[Scott Deboy]

I pushed branch "chainsaw-with-log4j1-dep" representing the working
log4j1 code for those that want to easily see what used to exist.

I'll probably selectively incorporate pieces from that branch into master.

On 10/1/23, Christian Grobmeier  wrote:
>
> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
>> The ability to route events to tabs is a core feature in the code -
>> that's how Chainsaw log messages end up in a Chainsaw-specific tab -
>> but the ability to control that routing via a 'routing expression' was
>> nuked from app-wide preferences - another thing we should bring back.
>>
>> It looks like we lost a lot of prefs, both panel-level and app-wide
>> prefs.
>
> Yes, I think all prefs are somehow gone. At least everything that is writes
> to a file seems to be commented.
> I didn't remove those things yet, as they seemed to big and I didn't
> understand well how they'd work or how I would test (I lack the knowledge of
> how the UI should operate but only see what is there now)
>
>
>>
>> Scott
>>
>> On 10/1/23, Robert Middleton  wrote:
>>> I would say the saving/loading of settings is probably the main thing to
>>> fix - if I remember correctly, it kinda works at the moment.  Part of
>>> the
>>> issue with what it did before was that the settings were scattered among
>>> several different files with no apparent rhyme or reason, and converting
>>> them to one file I'm not sure if everything works.
>>>
>>> The one feature that I'm pretty sure doesn't exist is the ability to
>>> have
>>> multiple log messages go to one tab, but I don't think that is critical
>>> for
>>> release.  In order to properly support that I think requires a bit more
>>> planning on both the UI side(so you can know how things are routed) and
>>> on
>>> the back-end side(to do the actual routing).
>>>
>>> -Robert Middleton
>>>
>>> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier
>>> 
>>> wrote:
>>>
>>>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote:
>>>> > It's great to see the contribution, thanks Christian!
>>>> >
>>>> > I pulled down latest master and it looks like there are some UI
>>>> > glitches we should fix - for example, resizing the logger tree pane
>>>> > doesn't render correctly.
>>>> >
>>>> > As I mentioned before, I assume there are a bunch of features we lost
>>>> > when we moved from log4j1 - some may not be critical, but I think
>>>> > persisting 'default' tab settings is pretty important if it's not
>>>> >
>>>> > I'd like us to at least support the log4j2 zeroconf functionality as
>>>> > well as VFSLogFilePatternReceiver.
>>>> >
>>>> > I'm happy to dig in - will look at latest master and contribute.
>>>>
>>>> I would be more than glad if you could take some kind of a lead here.
>>>> My
>>>> Swing-foo is long time gone and so far I just tried to clean a few
>>>> things
>>>> or make the code more comprehensible.
>>>>
>>>> I will keep trying to extracting things, making classes a bit smaller
>>>> if
>>>> possible. I will closely follow what you are doing and try to learn
>>>> from
>>>> it.
>>>>
>>>> Maybe, once we can persist tab settings and then release it, no matter
>>>> how
>>>> the rest of the cleanup is.
>>>>
>>>>
>>>> >
>>>> > Scott
>>>> >
>>>> > On 10/1/23, Christian Grobmeier  wrote:
>>>> >> Hello,
>>>> >>
>>>> >> I am moving things around a lot. There is much refactoring that is
>>>> necessary
>>>> >> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs
>>>> >> is
>>>> >> so
>>>> >> complicated to understand that it prevents people from contributing
>>>> >> -
>>>> let
>>>> >> alone Swing, but we can't change that.
>>>> >>
>>>> >> Apart from usual refactorings, I wonder what should be the goal of
>>>> >> 2.2?
>>>> >>
>>>> >> I have already upgraded some dependencies that have security flaws.
>>>> >> 2
>>>> more
>>>> >> are in the pom, but they have no patched versions so far.
>>>> >>
>>>> >> Should we add at least one feature? Is there maybe one already in
>>>> >> that
>>>> >> I
>>>> >> missed?
>>>> >>
>>>> >> I would appreciate it if one of the more experienced Swing-devs here
>>>> could
>>>> >> advise or maybe contribute some code so we can justify a release.
>>>> >>
>>>> >> The next question would be:
>>>> >> How is chainsaw released at all?
>>>> >>
>>>> >> Kind regards,
>>>> >> Christian
>>>> >>
>>>>
>>>
>

Re: [chainsaw] What is necessary for a 2.2 release?

[Scott Deboy]

I'm working to restore all the menu items that were nuked, and the
prior LogUI/LogPanel functionality allowing config import.

It's a big task, and will likely result in some of the recent
LogUI/LogPanel refactoring being reverted, but will do what I can to
minimize the impact.

Scott

On 10/2/23, Christian Grobmeier  wrote:
> On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
>> At least two reasons I can think of:
>> 1. Xstream doesn’t work on all java versions as you saw
>> 2. Simplify by using the commons config instead of rolling our own.
>>
>> Each tab should now have just one config file, the idea being that you
>> can
>> now share config files between people.  Before each tab had at least
>> two(maybe three) files.  One was the xml config, one was a java
>> serialized
>> map.  Removing the java serialization is important.
>
> OK. Do you think something based on Jackson would be good? It's JSON
> though.
>
> From an example:
>
> ObjectMapper objectMapper = new ObjectMapper();
> Car car = new Car("yellow", "renault");
> objectMapper.writeValue(new File("target/car.json"), car);
>
> We could wrap this in some kind of class and make it accessible per "tab"
> (or whatever).
>
>
>>
>> -Robert Middleton
>>
>> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier 
>> wrote:
>>
>>>
>>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
>>> > Some(most?) of the settings should be saved:
>>> >
>>> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
>>> >
>>> > The stuff that is commented out should just be the old saving code
>>> > that
>>> > used XStream to save the data out.
>>>
>>> You made it using this commit (thank you, its easy to track):
>>>
>>> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
>>>
>>> One question: why did we remove Xstream? it seem there was an update
>>> late
>>> 2022 to address some security.
>>> Should we just re-enable it or was there other reasons too?
>>>
>>>
>>>
>>>
>>> >
>>> > -Robert Middleton
>>> >
>>> > On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier
>>> > >> >
>>> > wrote:
>>> >
>>> >>
>>> >> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
>>> >> > The ability to route events to tabs is a core feature in the code -
>>> >> > that's how Chainsaw log messages end up in a Chainsaw-specific tab
>>> >> > -
>>> >> > but the ability to control that routing via a 'routing expression'
>>> >> > was
>>> >> > nuked from app-wide preferences - another thing we should bring
>>> >> > back.
>>> >> >
>>> >> > It looks like we lost a lot of prefs, both panel-level and app-wide
>>> >> prefs.
>>> >>
>>> >> Yes, I think all prefs are somehow gone. At least everything that is
>>> >> writes to a file seems to be commented.
>>> >> I didn't remove those things yet, as they seemed to big and I didn't
>>> >> understand well how they'd work or how I would test (I lack the
>>> knowledge
>>> >> of how the UI should operate but only see what is there now)
>>> >>
>>> >>
>>> >> >
>>> >> > Scott
>>> >> >
>>> >> > On 10/1/23, Robert Middleton  wrote:
>>> >> >> I would say the saving/loading of settings is probably the main
>>> thing to
>>> >> >> fix - if I remember correctly, it kinda works at the moment.  Part
>>> >> >> of
>>> >> the
>>> >> >> issue with what it did before was that the settings were scattered
>>> among
>>> >> >> several different files with no apparent rhyme or reason, and
>>> converting
>>> >> >> them to one file I'm not sure if everything works.
>>> >> >>
>>> >> >> The one feature that I'm pretty sure doesn't exist is the ability
>>> >> >> to
>>> >> have
>>> >> >> multiple log messages go to one tab, but I don&

Re: [chainsaw] What is necessary for a 2.2 release?

[Scott Deboy]

I think persisting to json format makes sense/would be easy to consume
with tools if needed.

On 10/2/23, Robert Middleton  wrote:
>> OK. Do you think something based on Jackson would be good? It's JSON
>> though.
>
> We already have a dependency on genson for JSON parsing, so if we
> really want to use JSON that would make the most sense.  Commons
> config can read/write XML; currently I just have it configured to do
> properties files.  I think we can write our own reader/writer as well,
> but ultimately I don't think that there is anything special that we
> need that commons config doesn't provide us out of the box.
>
> -Robert Middleton
>
> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker  wrote:
>>
>> Jackson makes for a good library here because it also supports several
>> data formats (YAML, XML, HOCON, and all sorts of others, both textual and
>> binary) and is fairly extensible for hooking any custom serialization or
>> deserialization logic you need. Given the desire to avoid Java
>> serialization, it is perfectly reasonable to avoid XStream as that’s
>> basically Java serialization using XML with all the pitfalls that entails
>> (I dealt with this fairly extensively back in the Jenkins project which
>> used an old fork of XStream for managing config files and state).
>>
>> I haven’t used Commons Configuration before, but it seems fairly
>> appropriate for this sort of thing as well.
>>
>> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier 
>> > wrote:
>> >
>> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
>> >> At least two reasons I can think of:
>> >> 1. Xstream doesn’t work on all java versions as you saw
>> >> 2. Simplify by using the commons config instead of rolling our own.
>> >>
>> >> Each tab should now have just one config file, the idea being that you
>> >> can
>> >> now share config files between people.  Before each tab had at least
>> >> two(maybe three) files.  One was the xml config, one was a java
>> >> serialized
>> >> map.  Removing the java serialization is important.
>> >
>> > OK. Do you think something based on Jackson would be good? It's JSON
>> > though.
>> >
>> > From an example:
>> >
>> > ObjectMapper objectMapper = new ObjectMapper();
>> > Car car = new Car("yellow", "renault");
>> > objectMapper.writeValue(new File("target/car.json"), car);
>> >
>> > We could wrap this in some kind of class and make it accessible per
>> > "tab" (or whatever).
>> >
>> >
>> >>
>> >> -Robert Middleton
>> >>
>> >> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier
>> >> 
>> >> wrote:
>> >>
>> >>>
>> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
>> >>>> Some(most?) of the settings should be saved:
>> >>>>
>> >>> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
>> >>>>
>> >>>> The stuff that is commented out should just be the old saving code
>> >>>> that
>> >>>> used XStream to save the data out.
>> >>>
>> >>> You made it using this commit (thank you, its easy to track):
>> >>>
>> >>> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
>> >>>
>> >>> One question: why did we remove Xstream? it seem there was an update
>> >>> late
>> >>> 2022 to address some security.
>> >>> Should we just re-enable it or was there other reasons too?
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> -Robert Middleton
>> >>>>
>> >>>> On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier
>> >>>> > >>>>
>> >>>> wrote:
>> >>>>
>> >>>>>
>> >>>>> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
>> >>>>>> The ability to route events to tabs is a core feature in the code
>> >>>>>> -
>> >>>>>> that's how Chainsaw log messages end up in a Chainsaw-specific tab
>> >>>>>> -
>> >>>>>&g

Re: [chainsaw] What is necessary for a 2.2 release?

[Scott Deboy]

I started but haven't had much time this week. The UI updates driven by
settings changes are most of what I have left.

On Sun, Oct 8, 2023, 2:17 PM Christian Grobmeier 
wrote:

> geson seems to do a good job, like Jackson (same JSR).
> I'd like to move forward with JSON format for storing properties.
>
> I am not sure what the status currently is, if Scott is still working on
> it :) I could also make some kind of proposal or so for storing properties
>
> On Tue, Oct 3, 2023, at 01:20, Scott Deboy wrote:
> > I think persisting to json format makes sense/would be easy to consume
> > with tools if needed.
> >
> > On 10/2/23, Robert Middleton  wrote:
> >>> OK. Do you think something based on Jackson would be good? It's JSON
> >>> though.
> >>
> >> We already have a dependency on genson for JSON parsing, so if we
> >> really want to use JSON that would make the most sense.  Commons
> >> config can read/write XML; currently I just have it configured to do
> >> properties files.  I think we can write our own reader/writer as well,
> >> but ultimately I don't think that there is anything special that we
> >> need that commons config doesn't provide us out of the box.
> >>
> >> -Robert Middleton
> >>
> >> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker  wrote:
> >>>
> >>> Jackson makes for a good library here because it also supports several
> >>> data formats (YAML, XML, HOCON, and all sorts of others, both textual
> and
> >>> binary) and is fairly extensible for hooking any custom serialization
> or
> >>> deserialization logic you need. Given the desire to avoid Java
> >>> serialization, it is perfectly reasonable to avoid XStream as that’s
> >>> basically Java serialization using XML with all the pitfalls that
> entails
> >>> (I dealt with this fairly extensively back in the Jenkins project which
> >>> used an old fork of XStream for managing config files and state).
> >>>
> >>> I haven’t used Commons Configuration before, but it seems fairly
> >>> appropriate for this sort of thing as well.
> >>>
> >>> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier <
> grobme...@apache.org>
> >>> > wrote:
> >>> >
> >>> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
> >>> >> At least two reasons I can think of:
> >>> >> 1. Xstream doesn’t work on all java versions as you saw
> >>> >> 2. Simplify by using the commons config instead of rolling our own.
> >>> >>
> >>> >> Each tab should now have just one config file, the idea being that
> you
> >>> >> can
> >>> >> now share config files between people.  Before each tab had at least
> >>> >> two(maybe three) files.  One was the xml config, one was a java
> >>> >> serialized
> >>> >> map.  Removing the java serialization is important.
> >>> >
> >>> > OK. Do you think something based on Jackson would be good? It's JSON
> >>> > though.
> >>> >
> >>> > From an example:
> >>> >
> >>> > ObjectMapper objectMapper = new ObjectMapper();
> >>> > Car car = new Car("yellow", "renault");
> >>> > objectMapper.writeValue(new File("target/car.json"), car);
> >>> >
> >>> > We could wrap this in some kind of class and make it accessible per
> >>> > "tab" (or whatever).
> >>> >
> >>> >
> >>> >>
> >>> >> -Robert Middleton
> >>> >>
> >>> >> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier
> >>> >> 
> >>> >> wrote:
> >>> >>
> >>> >>>
> >>> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
> >>> >>>> Some(most?) of the settings should be saved:
> >>> >>>>
> >>> >>>
> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
> >>> >>>>
> >>> >>>> The stuff that is commented out should just be the old saving code
> >>> >>>> that
> >>> >>>> used XStream to save the data out.
> >>> >>>
&

Re: [chainsaw] What is necessary for a 2.2 release?

[Scott Deboy]

Hey great - yeah I'll go through and add some tickets.

The event routing mechanism is very simple - you define an expression
using the logging event attribute names, and the values in the logging
event are used to convert that expression into a concrete tab name,
where the events are routed.

Note, you can also define 'expression views', like DB views, where an
event matching the expression is added to the expression view tab, but
that's on top of the default routing.

On 10/13/23, Robert Middleton  wrote:
> For those of you who didn't see on slack: I did update Chainsaw last
> night so you can load/save receivers.  That brings Chainsaw back into
> a usable state(in my mind at least).  I need to check to ensure that
> everything gets saved properly, but that shouldn't be too hard.
>
> Scott, would you mind making some issues on github for features that
> are needed/were removed?  I think one of the biggest problems that I
> have seen with Chainsaw before is that there isn't a manual(at least
> now somewhat mitigated) and/or a list of features and how to use them,
> so I've just been going with what I feel makes the most sense to me.
>
> The one thing that Scott pointed out was the ability to route messages
> to tabs; all the plumbing for that should exist for the most part(each
> ChainsawReceiver can have 0...N ChainsawEventBatchListener objects).
> I'm not sure how best to let the user hook things up - some sort of
> visual programming/flow-based view would be very cool but also very
> complicated.
>
> -Robert Middleton
>
> On Mon, Oct 9, 2023 at 3:24 PM Christian Grobmeier 
> wrote:
>>
>> On Sun, Oct 8, 2023, at 23:19, Scott Deboy wrote:
>> > I started but haven't had much time this week. The UI updates driven by
>> > settings changes are most of what I have left.
>>
>> OK great to hear, in that case I hold myself back a little longer :)
>>
>> Thanks!
>>
>> >
>> > On Sun, Oct 8, 2023, 2:17 PM Christian Grobmeier 
>> > wrote:
>> >
>> >> geson seems to do a good job, like Jackson (same JSR).
>> >> I'd like to move forward with JSON format for storing properties.
>> >>
>> >> I am not sure what the status currently is, if Scott is still working
>> >> on
>> >> it :) I could also make some kind of proposal or so for storing
>> >> properties
>> >>
>> >> On Tue, Oct 3, 2023, at 01:20, Scott Deboy wrote:
>> >> > I think persisting to json format makes sense/would be easy to
>> >> > consume
>> >> > with tools if needed.
>> >> >
>> >> > On 10/2/23, Robert Middleton  wrote:
>> >> >>> OK. Do you think something based on Jackson would be good? It's
>> >> >>> JSON
>> >> >>> though.
>> >> >>
>> >> >> We already have a dependency on genson for JSON parsing, so if we
>> >> >> really want to use JSON that would make the most sense.  Commons
>> >> >> config can read/write XML; currently I just have it configured to
>> >> >> do
>> >> >> properties files.  I think we can write our own reader/writer as
>> >> >> well,
>> >> >> but ultimately I don't think that there is anything special that we
>> >> >> need that commons config doesn't provide us out of the box.
>> >> >>
>> >> >> -Robert Middleton
>> >> >>
>> >> >> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker 
>> >> >> wrote:
>> >> >>>
>> >> >>> Jackson makes for a good library here because it also supports
>> >> >>> several
>> >> >>> data formats (YAML, XML, HOCON, and all sorts of others, both
>> >> >>> textual
>> >> and
>> >> >>> binary) and is fairly extensible for hooking any custom
>> >> >>> serialization
>> >> or
>> >> >>> deserialization logic you need. Given the desire to avoid Java
>> >> >>> serialization, it is perfectly reasonable to avoid XStream as
>> >> >>> that’s
>> >> >>> basically Java serialization using XML with all the pitfalls that
>> >> entails
>> >> >>> (I dealt with this fairly extensively back in the Jenkins project
>> >> >>> which
>> >> >>> used an old fork of XStream for managing config files and state).
>>

Re: [chainsaw] Next steps? Or is it over?

[Scott Deboy]

I have dropped the ball here, but will commit to working on this, this year.

I want to preserve a bunch of what can be done in the
https://github.com/apache/logging-chainsaw/tree/chainsaw-with-log4j1-dep
branch, and some of that just isn't possible because equivalent
functionality was never added to log4j2.

Remote tailing via the VFSLogFilePatternReceiver, with the existing
filter and search support, is enough I think.

I'll jump in and help.

Scott

Scott

On 11/28/23, Christian Grobmeier  wrote:
> Hello,
>
> I have started to clean up a few things that seemed good to me.
> The last time I sent a message like this was 1.5 months ago, but there was
> not much progress in maintaining it.
>
> I am currently in a state where I slowly get what should be happening, but
> unfortunately, it does not.
> We are not ready to release a new version, nor do we know what is necessary
> to release one.
>
> We have lots of dead code in Chainsaw, and it is tough to understand "what
> should it do?"
>
> I move around many Swing components to understand better, because the code
> is complex. However, I didn't see how Chainsaw would do anything beneficial.
> It's not working at all.
>
> Yes, I now what a "receiver" is meant to do. But apart from this description
> we have no specific goal nor do we actually receive anything (or I don't
> know how).
>
> For an ordinary person, it seems impossible to connect to a running server
> to tail a log file (I am not sure if it should do it) or even analyze a
> regular log file.
>
> This is when either old committers step up to tell a new one, like me, what
> is going on or to set a specific goal that we want to reach with a new
> version of Chainsaw.
>
> It was fun to clean up, but we need to talk more about Chainsaw. As for me,
> it is unusable, hard to fix and we need a new set of goals and radical
> refactoring to make it work again. If we are not agreeing on what it should
> do, it's time to go dormant. I am sorry to say this, I like Chainsaw. But me
> alone - I can't fix it.
>
> Please let me know,
> Christian
>
>

Re: [chainsaw] Next steps? Or is it over?

[Scott Deboy]

I've fixed the logger tree split pane UI (left artifacts when you
drag), and I've added VFSLogFilePatternReceiver support and it works
fine.

To test VFSLogFilePatternReceiver:
* Start Chainsaw
* View, Show Receivers menu
* Hit the 'create' icon in the receivers pane
* Select 'New VFSLogFilePatternReceiver'

In the bottom section of the receivers pane, enter values for the
following attributes:

fileURL - provide a local text file path (triple-slashes in the URI), like:
file:///Users/sdeboy/somefile.txt

logFormat - just use a simple format for now:
MESSAGE

tailing:
true

* Click OK

A new tab with the receiver name - default is 'Receiver' - will be
created and entries from the log file will be routed there.

In a text editor, add some lines to the file and you'll see the new
lines appear in the bottom of the log table.

Scott



On 11/28/23, Christian Grobmeier  wrote:
> Hi Scott,
>
> I believe you; thanks for speaking up and being around.
>
> How can I help?
>
> I think Chainsaw needs to see a release soon, so what can I do to help you?
>
> I am glad to clean up things and whatever is necessary.
>
> Kind regards,
> Christian
>
> On Wed, Nov 29, 2023, at 00:15, Scott Deboy wrote:
>> I have dropped the ball here, but will commit to working on this, this
>> year.
>>
>> I want to preserve a bunch of what can be done in the
>> https://github.com/apache/logging-chainsaw/tree/chainsaw-with-log4j1-dep
>> branch, and some of that just isn't possible because equivalent
>> functionality was never added to log4j2.
>>
>> Remote tailing via the VFSLogFilePatternReceiver, with the existing
>> filter and search support, is enough I think.
>>
>> I'll jump in and help.
>>
>> Scott
>>
>> Scott
>>
>> On 11/28/23, Christian Grobmeier  wrote:
>>> Hello,
>>>
>>> I have started to clean up a few things that seemed good to me.
>>> The last time I sent a message like this was 1.5 months ago, but there
>>> was
>>> not much progress in maintaining it.
>>>
>>> I am currently in a state where I slowly get what should be happening,
>>> but
>>> unfortunately, it does not.
>>> We are not ready to release a new version, nor do we know what is
>>> necessary
>>> to release one.
>>>
>>> We have lots of dead code in Chainsaw, and it is tough to understand
>>> "what
>>> should it do?"
>>>
>>> I move around many Swing components to understand better, because the
>>> code
>>> is complex. However, I didn't see how Chainsaw would do anything
>>> beneficial.
>>> It's not working at all.
>>>
>>> Yes, I now what a "receiver" is meant to do. But apart from this
>>> description
>>> we have no specific goal nor do we actually receive anything (or I don't
>>> know how).
>>>
>>> For an ordinary person, it seems impossible to connect to a running
>>> server
>>> to tail a log file (I am not sure if it should do it) or even analyze a
>>> regular log file.
>>>
>>> This is when either old committers step up to tell a new one, like me,
>>> what
>>> is going on or to set a specific goal that we want to reach with a new
>>> version of Chainsaw.
>>>
>>> It was fun to clean up, but we need to talk more about Chainsaw. As for
>>> me,
>>> it is unusable, hard to fix and we need a new set of goals and radical
>>> refactoring to make it work again. If we are not agreeing on what it
>>> should
>>> do, it's time to go dormant. I am sorry to say this, I like Chainsaw. But
>>> me
>>> alone - I can't fix it.
>>>
>>> Please let me know,
>>> Christian
>>>
>>>
>

Re: [chainsaw] Next steps? Or is it over?

[Scott Deboy]

I'll go through the UI and re-add small features that I think are
critical but were lost in the log4j1-jettison effort.

I'll follow-up in a new thread.

Scott


On 11/28/23, Scott Deboy  wrote:
> I've fixed the logger tree split pane UI (left artifacts when you
> drag), and I've added VFSLogFilePatternReceiver support and it works
> fine.
>
> To test VFSLogFilePatternReceiver:
> * Start Chainsaw
> * View, Show Receivers menu
> * Hit the 'create' icon in the receivers pane
> * Select 'New VFSLogFilePatternReceiver'
>
> In the bottom section of the receivers pane, enter values for the
> following attributes:
>
> fileURL - provide a local text file path (triple-slashes in the URI), like:
> file:///Users/sdeboy/somefile.txt
>
> logFormat - just use a simple format for now:
> MESSAGE
>
> tailing:
> true
>
> * Click OK
>
> A new tab with the receiver name - default is 'Receiver' - will be
> created and entries from the log file will be routed there.
>
> In a text editor, add some lines to the file and you'll see the new
> lines appear in the bottom of the log table.
>
> Scott
>
>
>
> On 11/28/23, Christian Grobmeier  wrote:
>> Hi Scott,
>>
>> I believe you; thanks for speaking up and being around.
>>
>> How can I help?
>>
>> I think Chainsaw needs to see a release soon, so what can I do to help
>> you?
>>
>> I am glad to clean up things and whatever is necessary.
>>
>> Kind regards,
>> Christian
>>
>> On Wed, Nov 29, 2023, at 00:15, Scott Deboy wrote:
>>> I have dropped the ball here, but will commit to working on this, this
>>> year.
>>>
>>> I want to preserve a bunch of what can be done in the
>>> https://github.com/apache/logging-chainsaw/tree/chainsaw-with-log4j1-dep
>>> branch, and some of that just isn't possible because equivalent
>>> functionality was never added to log4j2.
>>>
>>> Remote tailing via the VFSLogFilePatternReceiver, with the existing
>>> filter and search support, is enough I think.
>>>
>>> I'll jump in and help.
>>>
>>> Scott
>>>
>>> Scott
>>>
>>> On 11/28/23, Christian Grobmeier  wrote:
>>>> Hello,
>>>>
>>>> I have started to clean up a few things that seemed good to me.
>>>> The last time I sent a message like this was 1.5 months ago, but there
>>>> was
>>>> not much progress in maintaining it.
>>>>
>>>> I am currently in a state where I slowly get what should be happening,
>>>> but
>>>> unfortunately, it does not.
>>>> We are not ready to release a new version, nor do we know what is
>>>> necessary
>>>> to release one.
>>>>
>>>> We have lots of dead code in Chainsaw, and it is tough to understand
>>>> "what
>>>> should it do?"
>>>>
>>>> I move around many Swing components to understand better, because the
>>>> code
>>>> is complex. However, I didn't see how Chainsaw would do anything
>>>> beneficial.
>>>> It's not working at all.
>>>>
>>>> Yes, I now what a "receiver" is meant to do. But apart from this
>>>> description
>>>> we have no specific goal nor do we actually receive anything (or I
>>>> don't
>>>> know how).
>>>>
>>>> For an ordinary person, it seems impossible to connect to a running
>>>> server
>>>> to tail a log file (I am not sure if it should do it) or even analyze a
>>>> regular log file.
>>>>
>>>> This is when either old committers step up to tell a new one, like me,
>>>> what
>>>> is going on or to set a specific goal that we want to reach with a new
>>>> version of Chainsaw.
>>>>
>>>> It was fun to clean up, but we need to talk more about Chainsaw. As for
>>>> me,
>>>> it is unusable, hard to fix and we need a new set of goals and radical
>>>> refactoring to make it work again. If we are not agreeing on what it
>>>> should
>>>> do, it's time to go dormant. I am sorry to say this, I like Chainsaw.
>>>> But
>>>> me
>>>> alone - I can't fix it.
>>>>
>>>> Please let me know,
>>>> Christian
>>>>
>>>>
>>
>

Re: [chainsaw] Question: oading/writing settings of ChainsawTabbedPane

[Scott Deboy]

That's great!

Global app settings used to be loaded on startup and saved on exit.

LogPanel-specific settings were persisted on exit and loaded on
startup on a per-tab-name basis, mostly using LogPanelpreferenceModel.

There are a few preferences I'd like to restore - the tab-expression
event routing mechanism and the ability to hide and show columns.

Scott

On 12/2/23, Christian Grobmeier  wrote:
> Hi,
>
> I re-added the load/write feature in ChainsawTabbedPane using JSON and
> Genson:
> https://github.com/apache/logging-chainsaw/blob/master/src/main/java/org/apache/log4j/chainsaw/components/tabbedpane/ChainsawTabbedPane.java#L126-L191
>
> If it works, I will refactor it further so we can reuse the writing and
> reading code for other components.
>
> I could not test it: writing and reading are not used, and I want to know
> when this should happen.
>
> Is it supposed to read this when we start the application and write it when
> the tab was changed?
>
> Kind regards,
> Christian
>
>

Re: [chainsaw] Status change?

[Scott Deboy]

Thank you for spending time working on it Christian.

I started contributing to Chainsaw in 2003. I agree. It's time.

The primary benefit of Chainsaw was its built-in support for real-time
tailing of ssh-accessible pattern-layout based logs  - something
Kibana doesn't support well, and something no-one ever really
understood about it.

It was always a dev-focused tool - it works great for local dev, and
works in some prod envs, if you spend enough time to get the setup to
work.

There was no great reason to move off of the log41 deps really - they
aren't used for anything other than parsing the patternlayout, but
log4j1 is dead, so I get it.

I use it for my work, and will continue to do so, but the
chainsaw-with-log4j1-dep branch. I may revert master back to that,
because why not.

+1

Thanks again for putting up with my persistence to try and make it
useful to folks - I appreciate it  :)

Scott


On 2/6/24, Christian Grobmeier  wrote:
> Hello
>
> we have had Chainsaw for a long time in our product list, and I can totally
> see that some - myself included - are emotionally attached to it. However,
> due to my work on it, I have given it some additional thought.
>
> After working with the Chainsaw code base for a while, I saw that many
> features were commented out and removed when migrating to Log4j 2.
>
> Some basic features, such as "Open Logfile to view it directly." were
> removed. It is already hard to recover the functionality since log4j-extras
> no longer exists. In addition, as I learned recently, Log4j 2 has removed
> the XML Formatter. The old implementation of Chainsaw could only open
> XML-formatted log files.
>
> Honestly, there is much work to make Chainsaw a working product again. I
> mostly did refactorings and clean-ups, but I am not even through. I could
> continue like this for two more months.
>
> Restoring the old functionality and making it functional again requires even
> more months.
> If we had completed it, we would have restored a Swing application, mostly
> replaced by Kibana stacks.
>
> At this point, I don't see how we can write the tons of code necessary, and
> also not how useful it would be. Either all our users are using Log4j 1, or
> we don't have any users at all for Chainsaw, since it didn't work.
>
> For that reason, I would like to propose to move Chainsaw to dormant. If we
> feel for it, we can work and fix it - we should not archive the repo. But I
> would like to make clear that Chainsaw is not in good shape, and people
> should only use it only "at their own risk."
>
> I would like to make clear that this proposal is not something I say easily,
> but I feel it is in the best interest of our users to communicate how we
> currently see the status of this project.
>
> Please note, that I don't have much time to continue to work on it in the
> next months.
>
> Remembering the last discussion about this: Scott, are you OK with that
> move? I know it's your baby, but as long as we don't have a working product,
> we should move it. I am open to moving it back when we somehow get rid of
> all the problems.
>
> Please let me know if one of you has an alternate proposal - we can also
> discuss it in the next call.
>
> Kind regards,
> Christian
>
> --
> The Apache Software Foundation
> V.P., Data Privacy
>

Re: [VOTE] Move Chainsaw to dormant

[Scott Deboy]

+1

Thanks Christian

Scott

On 2/12/24, Christian Grobmeier  wrote:
> Hello,
>
> This vote is to put Chainsaw to the "Dormant" components. There is much work
> to be done on this component, but not enough hours can be committed to do
> that work. To reflect this situation to the user, it is better to move
> Chainsaw to the dormant section and communicate it as "no longer
> maintained."  The component can be moved back to the "active" state whenever
> people are actively working on it. The main branch in the repository will be
> marked with the new state, but the repository will not be archived for now.
>
> Please note:
>
> [ ] +1, move to dormant
> [ ]  -1, don't because...
>
> I will leave this vote open for the usual 72 hours.
>
> Thank you!
>
> Kind regards,
> Christian
>