Re: [log4j] Unstable tests on Windows

[Volkan Yazıcı]

Yesterday I disabled one and created #2011
 (labeled with
`tests`) for it. You can navigate all `tests` labeled issues
 or simply search
for `@DisabledOnOs` in the code base – there are not many.

On Tue, Nov 28, 2023 at 6:01 AM Ralph Goers 
wrote:

> I would be -1 if the issues are going to be ignored or not tracked in any
> way. I don’t know if GitHub has something like a Jira Epic or if they can
> be tagged in some way so that they can be easily located but something like
> that would be fine. Even tracking them in Confluence would be fine.
>
> It would also be great if only the failing tests could be run under a
> profile making it easy to fix them.
>
> Hopefully you get what I mean. I am not looking for something complicated,
> just a way to make it easy to find them when someone has the urge to fix
> them.
>
> Ralph
>
> > On Nov 27, 2023, at 3:28 AM, Volkan Yazıcı  wrote:
> >
> > Ralph did not agree, but did not strongly object either. Ralph, are you
> -1
> > on disabling tests only Windows that are failing frequently on Windows
> and
> > capturing them in tickets to be addressed?
> >
> > On Thu, Nov 23, 2023 at 12:23 AM Christian Grobmeier <
> grobme...@apache.org>
> > wrote:
> >
> >> Ralph said, nobody would ever fix these tests if you do it like this. I
> >> think you should create the ticket but keep the tests until we find the
> >> issue. Otherwise there issues will rot
> >>
> >> On Wed, Nov 22, 2023, at 09:13, Volkan Yazıcı wrote:
> >>> AFAIC, nobody[1] shows a strong opposition against the idea of
> disabling
> >>> frequently failing Windows tests only on Windows and creating a ticket
> >> for
> >>> each one. I will proceed with that.
> >>>
> >>> [1] Except Piotr, whom I discussed the issue with in Slack and he
> agreed
> >>> with the above shared approach.
> >>>
> >>> On Mon, Nov 20, 2023 at 12:57 PM Volkan Yazıcı  wrote:
> >>>
>  I am not asking to disable Windows tests. I am asking to disable tests
>  and only those tests that have a failure rate on Windows higher than,
>  say, 30%. To be precise, I think there are 2-3 of them dealing with
>  network sockets and rolling file appenders. I am not talking about
>  dozens or such.
> 
>  After disabling them, we can create a ticket referencing them. So that
>  interested parties can fix them.
> 
>  On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz
>   wrote:
> >
> > Hi Volkan,
> >
> > On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı  wrote:
> >>
> >> As Gary (the only Windows user among the active Log4j maintainers,
> >> AFAIK) has noticed several times, Log4j tests on Windows are pretty
> >> unstable. It not only fails on Gary's laptop, but Piotr and I need
> >> to
> >> give Windows tests in CI a kick on a regular basis. Approximately
> >> one
> >> out of three CI runs fails on Windows. Piotr already improved the
> >> situation extensively, though there are still several leftovers that
> >> need attention.
> >>
> >> Unless somebody steps up to improve the unstable Windows tests, I
> >> would like to disable those only for the WIndows platform.
> >
> > Please don't. Windows has an annoying file locking policy that
> > prevents users from deleting files with open file descriptors, but
> > that is one of the few ways to detect resource leakage we have.
> >
> > Tests running on *NIXes will ignore problems with open file
> > descriptors and delete the log files, but on a production system
> those
> > leaks will accumulate and cause application crashes. We had such a
> > leak, when we used `URLConnection#getLastModified` on a `jar:...`
> URL.
> > This call caused file descriptor exhaustion on both Windows and
> > *NIXes, but only the Windows test was able to detect it.
> >
> > Piotr,
> > who never thought would ever defend Microsoft Windows.
> >
> > PS: Gary reports the failures, but always runs the build again until
> > it succeeds, even on Friday 13th, when he had to wait until Saturday
> > 14th for the test run to succeed.
> 
> >>
>
>

Re: [log4j] Unstable tests on Windows

[Piotr P. Karwasz]

Hi Ralph,

On Tue, 28 Nov 2023 at 06:01, Ralph Goers  wrote:
>
> I would be -1 if the issues are going to be ignored or not tracked in any 
> way. I don’t know if GitHub has something like a Jira Epic or if they can be 
> tagged in some way so that they can be easily located but something like that 
> would be fine. Even tracking them in Confluence would be fine.

In Github Issues you can create a parent/child relationship between
using task lists, e.g.:
https://github.com/apache/logging-log4j2/issues/2014

We probably should also add a JUnit 5 tag for the tests that we
disable, so that we can just run those from the CLI.

Piotr

[log4j] Releasing Log4j `3.0.0`

[Volkan Yazıcı]

I plan to work on `main` until February, finalize recycler implementation,
carry out whatever improvement I can, and release `3.0.0`.

*If you have any objections with this plan, or if you have things to do on
`main` and you cannot comply with this schedule, etc., let's discuss.* I
want to agree on a plan and timeline that works for you.

*Personal remark:* I am against releasing `3.0.0` from `main`. `2.x`
changes that didn't go into `main` are titanic. `main` also contains
several incomplete code, doc, or both. I support the idea of forking `3.x`
from `2.x`, backporting crucial features from `main` to `3.x`, and then
releasing `3.0.0`. I had several email, Slack, and video conversations with
Ralph, Matt, and Piotr. They don't agree with me. Ralph even threatened to
veto all non-bugfix changes on `2.x`
. I am
outnumbered and I accept the defeat. Let's release `3.0.0` from `main` and
move on. I don't want to spend time discussing this subject further.

Re: [log4j] Releasing Log4j `3.0.0`

[Piotr P. Karwasz]

Hi Volkan,

On Tue, 28 Nov 2023 at 11:20, Volkan Yazıcı  wrote:
> *Personal remark:* I am against releasing `3.0.0` from `main`. `2.x`
> changes that didn't go into `main` are titanic. `main` also contains
> several incomplete code, doc, or both. I support the idea of forking `3.x`
> from `2.x`, backporting crucial features from `main` to `3.x`, and then
> releasing `3.0.0`. I had several email, Slack, and video conversations with
> Ralph, Matt, and Piotr. They don't agree with me.

The number of changes in `main` that didn't go to `2.x` is also
titanic. We all agree we are in the middle of a large river, the only
thing were our opinions differ is which shore is closer.

As an example: `log4j-jakarta-web` in 2.x (and even in main) was
missing three important changes that were only present in `log4j-web`
(main branch).

What you can do is to:

 * for each module, except the big ones (`log4j-api`, `log4j-core`,
`log4j-1.2-api`, `log4j-layout-template-json`) open a Github issue to
ask people to check the differences between `main` and `2.x` and
remove the regressions,
 * for the big modules: you can check JTL, I can check the 1.2 bridge
and you can split `log4j-core` into smaller (package-size?) chunks and
open issues for them,
 * regarding `log4j-api` we'll talk on Sunday.

BTW: Matt or Volkan, can you set up a meeting with Google or Zoom for
Sunday (20:00 UTC I presume)?

Piotr

Re: [log4j] Unstable tests on Windows

[Gary Gregory]

I think JUnit can group tests in categories with annotations (AFK).

Gary

On Tue, Nov 28, 2023, 12:01 AM Ralph Goers 
wrote:

> I would be -1 if the issues are going to be ignored or not tracked in any
> way. I don’t know if GitHub has something like a Jira Epic or if they can
> be tagged in some way so that they can be easily located but something like
> that would be fine. Even tracking them in Confluence would be fine.
>
> It would also be great if only the failing tests could be run under a
> profile making it easy to fix them.
>
> Hopefully you get what I mean. I am not looking for something complicated,
> just a way to make it easy to find them when someone has the urge to fix
> them.
>
> Ralph
>
> > On Nov 27, 2023, at 3:28 AM, Volkan Yazıcı  wrote:
> >
> > Ralph did not agree, but did not strongly object either. Ralph, are you
> -1
> > on disabling tests only Windows that are failing frequently on Windows
> and
> > capturing them in tickets to be addressed?
> >
> > On Thu, Nov 23, 2023 at 12:23 AM Christian Grobmeier <
> grobme...@apache.org>
> > wrote:
> >
> >> Ralph said, nobody would ever fix these tests if you do it like this. I
> >> think you should create the ticket but keep the tests until we find the
> >> issue. Otherwise there issues will rot
> >>
> >> On Wed, Nov 22, 2023, at 09:13, Volkan Yazıcı wrote:
> >>> AFAIC, nobody[1] shows a strong opposition against the idea of
> disabling
> >>> frequently failing Windows tests only on Windows and creating a ticket
> >> for
> >>> each one. I will proceed with that.
> >>>
> >>> [1] Except Piotr, whom I discussed the issue with in Slack and he
> agreed
> >>> with the above shared approach.
> >>>
> >>> On Mon, Nov 20, 2023 at 12:57 PM Volkan Yazıcı  wrote:
> >>>
>  I am not asking to disable Windows tests. I am asking to disable tests
>  and only those tests that have a failure rate on Windows higher than,
>  say, 30%. To be precise, I think there are 2-3 of them dealing with
>  network sockets and rolling file appenders. I am not talking about
>  dozens or such.
> 
>  After disabling them, we can create a ticket referencing them. So that
>  interested parties can fix them.
> 
>  On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz
>   wrote:
> >
> > Hi Volkan,
> >
> > On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı  wrote:
> >>
> >> As Gary (the only Windows user among the active Log4j maintainers,
> >> AFAIK) has noticed several times, Log4j tests on Windows are pretty
> >> unstable. It not only fails on Gary's laptop, but Piotr and I need
> >> to
> >> give Windows tests in CI a kick on a regular basis. Approximately
> >> one
> >> out of three CI runs fails on Windows. Piotr already improved the
> >> situation extensively, though there are still several leftovers that
> >> need attention.
> >>
> >> Unless somebody steps up to improve the unstable Windows tests, I
> >> would like to disable those only for the WIndows platform.
> >
> > Please don't. Windows has an annoying file locking policy that
> > prevents users from deleting files with open file descriptors, but
> > that is one of the few ways to detect resource leakage we have.
> >
> > Tests running on *NIXes will ignore problems with open file
> > descriptors and delete the log files, but on a production system
> those
> > leaks will accumulate and cause application crashes. We had such a
> > leak, when we used `URLConnection#getLastModified` on a `jar:...`
> URL.
> > This call caused file descriptor exhaustion on both Windows and
> > *NIXes, but only the Windows test was able to detect it.
> >
> > Piotr,
> > who never thought would ever defend Microsoft Windows.
> >
> > PS: Gary reports the failures, but always runs the build again until
> > it succeeds, even on Friday 13th, when he had to wait until Saturday
> > 14th for the test run to succeed.
> 
> >>
>
>

Re: [log4j] Releasing Log4j `3.0.0`

[Gary Gregory]

I'm OK with either direction for merges for anything between 2.x and 3.x
branches for now and certainly until 3.x makes it out as a release. I won't
argue for or against either.

As a semi aside, in Commons, I circumvented the whole JPMS garbage, its
split module horror show for tests by letting the Moditect Maven plug in
generate module info files at build time.

Maybe that could be an interesting investigation for Log4j, not that I want
to take the time to do it ATM.

Gary


On Tue, Nov 28, 2023, 5:20 AM Volkan Yazıcı  wrote:

> I plan to work on `main` until February, finalize recycler implementation,
> carry out whatever improvement I can, and release `3.0.0`.
>
> *If you have any objections with this plan, or if you have things to do on
> `main` and you cannot comply with this schedule, etc., let's discuss.* I
> want to agree on a plan and timeline that works for you.
>
> *Personal remark:* I am against releasing `3.0.0` from `main`. `2.x`
> changes that didn't go into `main` are titanic. `main` also contains
> several incomplete code, doc, or both. I support the idea of forking `3.x`
> from `2.x`, backporting crucial features from `main` to `3.x`, and then
> releasing `3.0.0`. I had several email, Slack, and video conversations with
> Ralph, Matt, and Piotr. They don't agree with me. Ralph even threatened to
> veto all non-bugfix changes on `2.x`
> . I am
> outnumbered and I accept the defeat. Let's release `3.0.0` from `main` and
> move on. I don't want to spend time discussing this subject further.
>

Re: [log4j] Releasing Log4j `3.0.0`

[Ralph Goers]

> On Nov 28, 2023, at 7:21 AM, Gary Gregory  wrote:
> 
> I'm OK with either direction for merges for anything between 2.x and 3.x
> branches for now and certainly until 3.x makes it out as a release. I won't
> argue for or against either.
> 
> As a semi aside, in Commons, I circumvented the whole JPMS garbage, its
> split module horror show for tests by letting the Moditect Maven plug in
> generate module info files at build time.

Piotr used the bnd-maven-plugin to generate the module-info classes. However, 
that doesn’t really eliminate the “whole JPMS garbage” as we still have to test 
it.

Ralph

Re: [log4j] Releasing Log4j `3.0.0`

[Ralph Goers]

I do not understand what my email provider has against Volkan. Once again I did 
not receive his email. 

Looking at the archive I see you want to release 3.0.0 in February. That may be 
possible but that isn’t exactly what was discussed in the last video meeting we 
had. The meeting notes are at 
https://docs.google.com/document/d/1hab4-RTeG13CnH5OAJlYJicSJV_fJweCZ0s1dq_LZ_A/edit.
 However, in looking that I don’t see mention of releases. We discussed 
performing beta releases and at least one RC release before at GA release. As I 
recall we were talking about doing a release every 2 or 3 weeks until GA.

Ralph


> On Nov 28, 2023, at 3:55 AM, Piotr P. Karwasz  wrote:
> 
> Hi Volkan,
> 
> On Tue, 28 Nov 2023 at 11:20, Volkan Yazıcı  wrote:
>> *Personal remark:* I am against releasing `3.0.0` from `main`. `2.x`
>> changes that didn't go into `main` are titanic. `main` also contains
>> several incomplete code, doc, or both. I support the idea of forking `3.x`
>> from `2.x`, backporting crucial features from `main` to `3.x`, and then
>> releasing `3.0.0`. I had several email, Slack, and video conversations with
>> Ralph, Matt, and Piotr. They don't agree with me.
> 
> The number of changes in `main` that didn't go to `2.x` is also
> titanic. We all agree we are in the middle of a large river, the only
> thing were our opinions differ is which shore is closer.
> 
> As an example: `log4j-jakarta-web` in 2.x (and even in main) was
> missing three important changes that were only present in `log4j-web`
> (main branch).
> 
> What you can do is to:
> 
> * for each module, except the big ones (`log4j-api`, `log4j-core`,
> `log4j-1.2-api`, `log4j-layout-template-json`) open a Github issue to
> ask people to check the differences between `main` and `2.x` and
> remove the regressions,
> * for the big modules: you can check JTL, I can check the 1.2 bridge
> and you can split `log4j-core` into smaller (package-size?) chunks and
> open issues for them,
> * regarding `log4j-api` we'll talk on Sunday.
> 
> BTW: Matt or Volkan, can you set up a meeting with Google or Zoom for
> Sunday (20:00 UTC I presume)?
> 
> Piotr

Re: [log4j] Releasing Log4j `3.0.0`

[Volkan Yazıcı]

Okay. I will do the next beta release sometime this week. We can do more as
we see fit.

On Tue, 28 Nov 2023 at 15:59, Ralph Goers 
wrote:

> I do not understand what my email provider has against Volkan. Once again
> I did not receive his email.
>
> Looking at the archive I see you want to release 3.0.0 in February. That
> may be possible but that isn’t exactly what was discussed in the last video
> meeting we had. The meeting notes are at
> https://docs.google.com/document/d/1hab4-RTeG13CnH5OAJlYJicSJV_fJweCZ0s1dq_LZ_A/edit.
> However, in looking that I don’t see mention of releases. We discussed
> performing beta releases and at least one RC release before at GA release.
> As I recall we were talking about doing a release every 2 or 3 weeks until
> GA.
>
> Ralph
>
>
> > On Nov 28, 2023, at 3:55 AM, Piotr P. Karwasz 
> wrote:
> >
> > Hi Volkan,
> >
> > On Tue, 28 Nov 2023 at 11:20, Volkan Yazıcı  wrote:
> >> *Personal remark:* I am against releasing `3.0.0` from `main`. `2.x`
> >> changes that didn't go into `main` are titanic. `main` also contains
> >> several incomplete code, doc, or both. I support the idea of forking
> `3.x`
> >> from `2.x`, backporting crucial features from `main` to `3.x`, and then
> >> releasing `3.0.0`. I had several email, Slack, and video conversations
> with
> >> Ralph, Matt, and Piotr. They don't agree with me.
> >
> > The number of changes in `main` that didn't go to `2.x` is also
> > titanic. We all agree we are in the middle of a large river, the only
> > thing were our opinions differ is which shore is closer.
> >
> > As an example: `log4j-jakarta-web` in 2.x (and even in main) was
> > missing three important changes that were only present in `log4j-web`
> > (main branch).
> >
> > What you can do is to:
> >
> > * for each module, except the big ones (`log4j-api`, `log4j-core`,
> > `log4j-1.2-api`, `log4j-layout-template-json`) open a Github issue to
> > ask people to check the differences between `main` and `2.x` and
> > remove the regressions,
> > * for the big modules: you can check JTL, I can check the 1.2 bridge
> > and you can split `log4j-core` into smaller (package-size?) chunks and
> > open issues for them,
> > * regarding `log4j-api` we'll talk on Sunday.
> >
> > BTW: Matt or Volkan, can you set up a meeting with Google or Zoom for
> > Sunday (20:00 UTC I presume)?
> >
> > Piotr
>
>

[chainsaw] Next steps? Or is it over?

[Christian Grobmeier]

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

[Christian Grobmeier]

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