Re: [VOTE] Release Apache Log4j Tools 0.5.0
One day this will work in my fantasy world: shasum --check apache-log4j-tools-0.5.0-src.zip.sha512 shasum: apache-log4j-tools-0.5.0-src.zip.sha512: no properly formatted SHA checksum lines found ;-) Gary On Fri, Sep 29, 2023 at 5:03 PM Christian Grobmeier wrote: > > +1 > > > > On Fri, Sep 29, 2023, at 13:13, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Tools 0.5.0. > > > > Source repository: https://github.com/apache/logging-log4j-tools > > Commit: 861b03c70a76ca19408ffc8c4a77bc0c4e5e4570 > > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools > > Nexus: > > https://repository.apache.org/content/repositories/orgapachelogging-1187 > > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > > > Please download, test, and cast your votes on this mailing list. > > > > [ ] +1, release the artifacts > > [ ] -1, don't release, 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 to test the release, but only the Logging Services PMC > > votes are officially counted. At least 3 +1 votes and more > > positive than negative votes are required. > > > > === Release Notes > > > > This minor release contains various bug fixes and improvements. > > > > Added > > > > * Started publishing the project website[1] > > > > [1] https://logging.staged.apache.org/log4j/tools > > > > Changed > > > > * Made `author` element optional and bumped the XML schema version to > > `0.1.2` (#81) > > * Make `log4j-changelog-maven-plugin` thread-safe (#80) > > * Update `org.apache.logging:logging-parent` to version `10.1.0` (#82) > > * Update `org.junit.jupiter:junit-jupiter-engine` to version `5.10.0`
Re: [VOTE] Release Apache Log4j Tools 0.5.0
[Note to reviewers: You MUST review a src package, not a git tag.]
-1: Failure running 'mvn clean verify'
mvn clean verify
Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /usr/local/Cellar/maven/3.9.4/libexec
Java version: 17.0.8.1, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for org.apache.logging.log4j:log4j-tools-bom:pom:0.5.0
[WARNING] 'parent.relativePath' of POM
org.apache.logging.log4j:log4j-tools-bom:${revision}
(/Users/garydgregory/rc/tool/pom.xml) points at
org.apache.logging.log4j:log4j-tools-bom instead of
org.apache.logging:logging-parent, please verify your project
structure @ org.apache.logging.log4j:log4j-tools-bom:${revision},
/Users/garydgregory/rc/tool/pom.xml, line 31, column 11
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
[WARNING]
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] log4j-tools-bom[pom]
[INFO] log4j-tools-parent [pom]
[INFO] log4j-changelog[jar]
[INFO] log4j-changelog-maven-plugin [maven-plugin]
[INFO]
[INFO] --< org.apache.logging.log4j:log4j-tools-bom >--
[INFO] Building log4j-tools-bom 0.5.0 [1/4]
[INFO] from pom.xml
[INFO] [ pom ]-
Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/xml-maven-plugin/1.1.0/xml-maven-plugin-1.1.0.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/xml-maven-plugin/1.1.0/xml-maven-plugin-1.1.0.pom
(8.5 kB at 29 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/xml-maven-plugin/1.1.0/xml-maven-plugin-1.1.0.jar
Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/xml-maven-plugin/1.1.0/xml-maven-plugin-1.1.0.jar
(65 kB at 923 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-changelog-maven-plugin/0.4.0/log4j-changelog-maven-plugin-0.4.0.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-changelog-maven-plugin/0.4.0/log4j-changelog-maven-plugin-0.4.0.pom
(2.7 kB at 69 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-tools-parent/0.4.0/log4j-tools-parent-0.4.0.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-tools-parent/0.4.0/log4j-tools-parent-0.4.0.pom
(4.8 kB at 123 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-tools-bom/0.4.0/log4j-tools-bom-0.4.0.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-tools-bom/0.4.0/log4j-tools-bom-0.4.0.pom
(4.3 kB at 87 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-changelog-maven-plugin/0.4.0/log4j-changelog-maven-plugin-0.4.0.jar
Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-changelog-maven-plugin/0.4.0/log4j-changelog-maven-plugin-0.4.0.jar
(15 kB at 322 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/flatten-maven-plugin/1.5.0/flatten-maven-plugin-1.5.0.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/flatten-maven-plugin/1.5.0/flatten-maven-plugin-1.5.0.pom
(11 kB at 234 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/flatten-maven-plugin/1.5.0/flatten-maven-plugin-1.5.0.jar
Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/flatten-maven-plugin/1.5.0/flatten-maven-plugin-1.5.0.jar
(120 kB at 2.0 MB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/com/diffplug/spotless/spotless-maven-plugin/2.39.0/spotless-maven-plugin-2.39.0.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/com/diffplug/spotless/spotless-maven-plugin/2.39.0/spotless-maven-plugin-2.39.0.pom
(3.1 kB at 121 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/com/diffplug/spotless/spotless-maven-plugin/2.39.0/spotless-maven-plugin-2.39.0.jar
Downloaded from central:
https://repo.maven.apache.org/maven2/com/diffplug/spotless/spotless-maven-plugin/2.39.0/spotless-mave
Re: [VOTE] Release Apache Log4j Tools 0.5.0
Hi Gary, On Sun, 1 Oct 2023 at 14:20, Gary Gregory wrote: > > [Note to reviewers: You MUST review a src package, not a git tag.] > > -1: Failure running 'mvn clean verify' Nice catch. The problem comes from the modification date of each file in the source archive (i.e. start of the epoch). In this case the Maven Resources Plugin fails to copy `src/main/resources/log4j-changelog.xsd` to `target/classes/log4j-changelog.xsd`, because the source modification date is 0, while the destination modification date is 0 (the file does not exist). Granted that this seems like a bug in the Maven Resources Plugin, but we should fix the modification dates in the archive. I am also voting -1. Piotr
Re: [VOTE] Release Apache Log4j Kotlin API 1.3.0
I wonder if the moditect plug in would do the heavy lifting for us here. It
will automatically generate module info files. That's what we in over at
Commons FWIW.
Gary
On Sat, Sep 30, 2023, 5:29 PM Piotr P. Karwasz
wrote:
> Hi Volkan,
>
> On Thu, 28 Sept 2023 at 15:25, Volkan Yazıcı wrote:
> > Please download, test, and cast your votes on this mailing list.
> >
> > [ ] +1, release the artifacts
> > [ ] -1, don't release, because...
>
> Sorry for joining the party late, but I wanted to perform a test with
> Kotlin + JPMS.
>
> Even if everything else looks fine the module descriptor is:
>
> module org.apache.logging.log4j.api_kotlin {
> requires java.base;
> requires kotlin-reflect;
> requires kotlin-stdlib;
> requires kotlin-stdlib-common;
> requires kotlinx-coroutines-core-jvm;
> requires log4j-api;
>
> exports org.apache.logging.log4j.kotlin;
> }
>
> I am afraid I'll have to vote:
>
> -1, don't release, because the name of the JPMS module for `log4j-api`
> is `org.apache.logging.log4j`.
>
> I only have a basic understanding of Kotlin, but are all those Kotlin
> modules required? I believe we could have a basic "Hello world!"
> program with just "kotlin-stdlib" and
> "org.apache.logging.log4j.api_kotlin".
>
> Piotr
>
[chainsaw] What is necessary for a 2.2 release?
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?
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?
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?
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?
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?
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?
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?
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?
On Sun, Oct 1, 2023, at 22:09, Scott Deboy wrote: > 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. I think thats a great idea. I will be very busy for the next week, so I am not going to make many changes then. However, when I return I plan to work further on the LogPanel and cut it into pieces, so it is (hopefully) easier to maintain. Kind regards, Christian > > 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?
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. -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'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 < > grobme...@apache.org> > >> 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 > >>> >> > >>> > >> >
