[VOTE] Release Apache Log4j 2.21.0
This is a vote to release the Apache Log4j 2.21.0. Website: https://logging-log4j.staged.apache.org/log4j/2.x/ GitHub: https://github.com/apache/logging-log4j2 Commit: 493d9a9daabc72d10582c4682538baa93a2a Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1202 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. == Release Notes This release primarily focuses on enhancements to our OSGi and JPMS support and contains several bug fixes. It will be the first release built and signed by the CI using the https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0&op=index[ASF Logging Services Release Manager GPG key], which is shared in https://www.apache.org/dist/logging/KEYS[KEYS]. The Log4j 2.21.0 API, as well as the other artifacts, maintains binary compatibility with the previous release. Apache Log4j 2.21.0 requires Java 8 to run. The build requires JDK 11 and generates reproducible binaries. For complete information on Apache Log4j 2, including instructions on how to submit bug reports, patches, get support, or suggestions for improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j 2 website]. === OSGi changes All the published artifacts are OSGi bundles or fragments. This release introduces a change in the bundle symbolic names to allow them to function as JPMS module name: all hyphens `-` present in the bundle names of previous releases were replaced by dots `.`. === JPMS changes All the published artifacts have been migrated from automatic modules to named JPMS modules. All packages marked as private in the Javadoc are not exported. The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`, `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the same convention as the OSGi bundle names. === Added * Added marker parent support to `JsonTemplateLayout` (#1381) * Added https://facebook.github.io/zstd/[ZStandard compression] support (#1508, #1514) * Added a warning for incorrect syntax of highlighting styles (#1545, #1637) === Changed * Open `FileExtension` methods to allow their usage in custom ``RolloverStrategy``s (#1365, #1683) * Bumped the minimum Java version required for the build to JDK 11. Runtime requirements remain unchanged. (#1369) * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to `OFF` and `ALL`, respectively (#1503) * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550) * Use Java version-specific warnings in `StackLocator` (#1760) * Started logging a status error event instead of an NPE in `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has no valid `BundleContext` for a service type * Implemented a CI-based release process * Update Eclipse Angus Activation to version https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1] (#1591) * Update Eclipse Angus Mail to version https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2] (#1591) * Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5 (#1591) * Update Apache Cassandra to version https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16] (#1591) * Update Apache Commons Compress to version https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0] (#1591) * Update Apache Commons CSV to version https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0] (#1591) * Update Jackson to version https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2] (#1591) * Update Jakarta Activation API to version https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] (#1591) * Update Jakarta Mail API to version https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591) * Update JCTools to version https://github.com/JCTools/JCTools/blob/master/RELEASE-NOTES.md[4.0.1] (#1591) * Update Apache Kafka to version https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html[3.4.0] (#1591) * Update Kubernetes client to version https://github.com/fabric8io/kubernetes-client/releases?q=5.12.4[5.12.4] (#1591) * Update `org.mongodb:mongodb-driver-core` to version 4.10.2 (#1591) * Update `io.netty:netty-bom` to version 4.1.97 (#1591) * Update Spring Boot to version https://github.com/spring-projects/spring-boot/releases/tag/v2.7.15[2.7.15] (#1591) * Update Spring Framework to version https://github.com/spring-projects/spring-framework/releases/tag/v5.3.29[5.3.29] (#1591) * Update Tomcat JULI
Re: [VOTE] Release Apache Log4j 2.21.0
✔ Binaries ✔ Sources ✔ Website (incl. Javadocs) 𐄂 Website URL[1] ✔ Signatures ✔ Checksums +1 Thanks for taking care of the release Christian! [1] Christian's recent Jekyll experiment on the `asf-staging` branch of `logging-site` repository confused the INFRA and it is acting strangely. This will *NOT* be an issue when we push the website changes to production, i.e., `asf-site` branch. Though we will try fixing `asf-staging` anyway in the meantime. This release incorporates a humongous amount of infrastructural changes to the project that Piotr and I have been working on for months. My personal favorites: 1. Support for parallel Maven builds! First run is always a bumpy one due to the mysterious ways plugins operate. Though so far I have been enjoying `./mvnw -T2C install -DskipTests` or `./mvnw verify -T2C -pl \!:log4j-mongodb3,\!:log4j-mongodb4` a lot! See the `-T2C` there? Yup! (Embedded MongoDb server library's initial setup functionally doesn't support concurrent runs.) 2. Stellar CI support! We migrated all Maven-based projects (`logging-parent`, `-log4j2`, `-log4j-tools`, `-log4j-scala`, `-log4j-kotlin`, `-log4j-transform`, `-log4j-jmx-gui`) to a unified CI infrastructure where they all share the same automated release process and `dependabot` auto-merge voodoo! Christian single-handedly cutting this release himself is a solid proof of this convenience. 3. Major-version-specific URL convenience: https://logging.apache.org/log4j/kotlin/latest (redirected to `1.x`) https://logging.apache.org/log4j/kotlin/1.x Notice the `latest` and `1.x`? We *will* apply the same practice to Log4j too. You will eventually be seeing: https://logging.apache.org/log4j/latest (redirected to `2.x`) https://logging.apache.org/log4j/1.x https://logging.apache.org/log4j/2.x https://logging.apache.org/log4j/3.x 4. Every dependency that is upgradable is upgraded. On Fri, Oct 13, 2023 at 11:09 AM Christian Grobmeier wrote: > > This is a vote to release the Apache Log4j 2.21.0. > > Website: https://logging-log4j.staged.apache.org/log4j/2.x/ > GitHub: https://github.com/apache/logging-log4j2 > Commit: 493d9a9daabc72d10582c4682538baa93a2a > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1202 > 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. > > == Release Notes > > This release primarily focuses on enhancements to our OSGi and JPMS support > and contains several bug fixes. > It will be the first release built and signed by the CI using the > https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0&op=index[ASF > Logging Services Release Manager GPG key], which is shared in > https://www.apache.org/dist/logging/KEYS[KEYS]. > > The Log4j 2.21.0 API, as well as the other artifacts, maintains binary > compatibility with the previous release. > > Apache Log4j 2.21.0 requires Java 8 to run. > The build requires JDK 11 and generates reproducible binaries. > > For complete information on Apache Log4j 2, including instructions on how to > submit bug reports, patches, get support, or suggestions for improvement, see > http://logging.apache.org/log4j/2.x/[the Apache Log4j 2 website]. > > === OSGi changes > > All the published artifacts are OSGi bundles or fragments. > > This release introduces a change in the bundle symbolic names to allow them > to function as JPMS module name: all hyphens `-` present in the bundle names > of previous releases were replaced by dots `.`. > > === JPMS changes > > All the published artifacts have been migrated from automatic modules to > named JPMS modules. > All packages marked as private in the Javadoc are not exported. > > The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`, > `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the same > convention as the OSGi bundle names. > > > === Added > > * Added marker parent support to `JsonTemplateLayout` (#1381) > * Added https://facebook.github.io/zstd/[ZStandard compression] support > (#1508, #1514) > * Added a warning for incorrect syntax of highlighting styles (#1545, #1637) > > === Changed > > * Open `FileExtension` methods to allow their usage in custom > ``RolloverStrategy``s (#1365, #1683) > * Bumped the minimum Java version required for the build to JDK 11. Runtime > requirements remain unchanged. (#1369) > * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to `OFF` > and `ALL`, respectively (#1503) > * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550) > * U
Re: [VOTE] Release Apache Log4j 2.21.0
Hi all, On Fri, 13 Oct 2023 at 12:16, Volkan Yazıcı wrote: > > ✔ Binaries > ✔ Sources > ✔ Website (incl. Javadocs) > 𐄂 Website URL[1] > ✔ Signatures > ✔ Checksums > > +1 Same here: * the binaries in the binary archive, Maven repo and locally generated are identical. Somehow `log4j-perf` made it to the Maven repo, but I don't consider it a major problem, * the website looks Ok. +1 > Thanks for taking care of the release Christian! Same here. > [1] Christian's recent Jekyll experiment on the `asf-staging` branch > of `logging-site` repository confused the INFRA and it is acting > strangely. This will *NOT* be an issue when we push the website > changes to production, i.e., `asf-site` branch. Though we will try > fixing `asf-staging` anyway in the meantime. I think that the problem is that the `asf-staging` branch in `logging-site` has switched from a `content` folder to an `output` folder, while some of our 6 other site repos have a `content` folder. It is fixable, but INFRA offers us an infinite number of `logging-.staged.apache.org` domains and I think we should use it. Whenever we stage the website of a `foo` subproject we can: * branch `asf-site` into a `site/foo` branch to be staged on `logging-foo.staged.apache.org`, * review the website, * when `foo` is released we can just fast-forward `asf-site` to `site/foo`. Worst case scenario (if we have multiple votes at the same time), we can rebase `site/foo` on the current `asf-site` and merge it. > 1. Support for parallel Maven builds! First run is always a bumpy one > due to the mysterious ways plugins operate. Though so far I have been > enjoying `./mvnw -T2C install -DskipTests` or `./mvnw verify -T2C -pl > \!:log4j-mongodb3,\!:log4j-mongodb4` a lot! See the `-T2C` there? Yup! > (Embedded MongoDb server library's initial setup functionally doesn't > support concurrent runs.) Yes, Embedded MongoDB is quite error prone: it downloads a generic MongoDB binary release and runs it on the build host. Since these binaries depend on certain dynamic libraries, the tests can fail on some distributions. Gary, what do you think if we replace Embedded MongoDB with a Docker image? Piotr
Staging website (was: [VOTE] Release Apache Log4j 2.21.0)
>> [1] Christian's recent Jekyll experiment on the `asf-staging` branch >> of `logging-site` repository confused the INFRA and it is acting >> strangely. This will *NOT* be an issue when we push the website >> changes to production, i.e., `asf-site` branch. Though we will try >> fixing `asf-staging` anyway in the meantime. On Fri, Oct 13, 2023, at 13:28, Piotr P. Karwasz wrote: > I think that the problem is that the `asf-staging` branch in > `logging-site` has switched from a `content` folder to an `output` > folder, while some of our 6 other site repos have a `content` folder. > It is fixable, but INFRA offers us an infinite number of > `logging-.staged.apache.org` domains and I think we should use > it. According to this doc: https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-WebsitedeploymentserviceforGitrepositories We just have to give it a profile: staging: profile: mystuff Would result in: logging-mystuff.staged.apache.org I can easily migrate to this. The folder "output" is the default with ASF infra, but it is possible to replace it with content: jekyll: whoami: jekyll target: asf-staging outputdir: content Why is content not causing this issue? For me both is possible, just trying to understand the best way. Kind regards, Christian
Re: [VOTE] Release Apache Log4j Scala 13.0.0
Adding my +1. With that, the release passes with 3 binding +1 votes from Piotr, Matt, and me. I will continue the release process. On Tue, Oct 10, 2023 at 1:21 PM Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Scala 13.0.0. > > Website: https://logging.staged.apache.org/log4j/scala > GitHub: https://github.com/apache/logging-log4j-scala > Commit: 980f4ed0ba53f93d1514df65ddafb6f97396a975 > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-scala > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1200 > 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. > > === Reproducibility > > The `log4j-api-scala_3.jar` artifact targeting Scala 3 in this release > is not reproducible due to a bug in the Scala 3 compiler[1]. (The > other 4 artifacts are reproducible!) Though I don't find this a > release blocker since we can verify that the difference breaking the > reproducibility is just a member ordering problem, which doesn't have > any practical effect from a user's point of view. > > [1] https://github.com/lampepfl/dotty/issues/18248 > > What about CI checks? > > Note that CI-based reproducibility checks pass, since the issue > appears to be only observable when sources are built on hosts with > different specs. > > How can I check the reproducibility myself? > > export > NEXUS_REPO=https://repository.apache.org/content/repositories/orgapachelogging-1200 > ./mvnw verify artifact:compare -Dreference.repo=$NEXUS_REPO > > How can I view the difference myself? > > ./mvnw package > mkdir t && cd $_ > wget > https://repository.apache.org/content/repositories/orgapachelogging-1200/org/apache/logging/log4j/log4j-api-scala_3/13.0.0/log4j-api-scala_3-13.0.0.jar > unzip log4j-api-scala_3-13.0.0.jar -d reference > unzip ../log4j-api-scala_3/target/log4j-api-scala_3-13.0.0.jar -d local > diff -r reference local > # `diff` will point out that only `LoggingContext$.class` doesn't match > javap 'reference/org/apache/logging/log4j/scala/LoggingContext$.class' > > reference.LoggingContext > javap 'local/org/apache/logging/log4j/scala/LoggingContext$.class' > > local.LoggingContext > diff -u reference.LoggingContext local.LoggingContext > > What is the difference? > > Decompiling and comparing `LoggingContext$.class` files produce the > following output: > > --- reference.LoggingContext 2023-10-10 12:58:35.188544183 +0200 > +++ local.LoggingContext 2023-10-10 12:58:41.152551071 +0200 > @@ -114,30 +114,30 @@ >public scala.collection.LazyZip2 lazyZip(scala.collection.Iterable); >public scala.collection.IterableFactory iterableFactory(); >public scala.Function1 compose(scala.Function1); > - public double apply$mcDI$sp(int); > - public double apply$mcDJ$sp(long); > - public double apply$mcDF$sp(float); > - public double apply$mcDD$sp(double); > + public int apply$mcII$sp(int); > + public int apply$mcIJ$sp(long); > + public int apply$mcIF$sp(float); > + public int apply$mcID$sp(double); >public boolean apply$mcZI$sp(int); >public boolean apply$mcZJ$sp(long); >public boolean apply$mcZF$sp(float); >public boolean apply$mcZD$sp(double); > - public long apply$mcJI$sp(int); > - public long apply$mcJJ$sp(long); > - public long apply$mcJF$sp(float); > - public long apply$mcJD$sp(double); > - public void apply$mcVI$sp(int); > - public void apply$mcVJ$sp(long); > - public void apply$mcVF$sp(float); > - public void apply$mcVD$sp(double); >public float apply$mcFI$sp(int); >public float apply$mcFJ$sp(long); >public float apply$mcFF$sp(float); >public float apply$mcFD$sp(double); > - public int apply$mcII$sp(int); > - public int apply$mcIJ$sp(long); > - public int apply$mcIF$sp(float); > - public int apply$mcID$sp(double); > + public void apply$mcVI$sp(int); > + public void apply$mcVJ$sp(long); > + public void apply$mcVF$sp(float); > + public void apply$mcVD$sp(double); > + public double apply$mcDI$sp(int); > + public double apply$mcDJ$sp(long); > + public double apply$mcDF$sp(float); > + public double apply$mcDD$sp(double); > + public long apply$mcJI$sp(int); > + public long apply$mcJJ$sp(long); > + public long apply$mcJF$sp(float); > + public long apply$mcJD$sp(double); >public scala.Option unapply(java.lang.Object); >public scala.PartialFunction elementWise(); >public scala.PartialFunction orElse(scala.PartialFunction); > > Why is it a simple ordering problem? > > Since `grep -E 'public (.+) apply\$' | sort` executed against bot
[ANNOUNCE] Apache Log4j Scala 13.0.0 released
Apache Log4j Scala team is pleased to announce the 13.0.0 release. This project provides a Scala-friendly interface to log against the Log4j API. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/scala === Release Notes The highlights of this major release are Scala 3 support, JPMS descriptors, and the switch to semantic versioning[2]. [2] https://semver.org Note that this release is still binary backward compatible with the earlier release `12.0`. Though we needed to bump the major version number for the semantic versioning switch to avoid the confusion related with version ordering. Added * Added support for Scala 3 (LOG4J2-3184, #26) * Added OSGi and JPMS support Changed * Bumped the Java version to 17 (Scala 2.10 and 2.11 targets still require Java 8 that build switches to using `maven-toolchains-plugin`) * Switch the CI to GitHub Actions * Switched from `sbt` to Maven to take advantage of `logging-parent` conveniences * Switched to semantic versioning * Updated `org.apache.logging.log4j:log4j-api` version to `2.20.0` * Update `org.apache.logging:logging-parent` to version `10.1.1` * Started using `log4j-changelog`
Re: [site] Jekyll proposal (in branch)
The current version is certainly way simpler than before, I liked it. I agree with moving every "data" (members, projects, etc.) to its own data file. I still prefer all typesetting performed in AsciiDoc. (I am not telling you to do so immediately. But that is where I'd like this initiative to go.) As you yourself experienced from first hand by breaking `logging.staged.apache.org` domain, anything INFRA supports comes with a big catch. I prefer rolling our own CI-triggered Jekyll compiler, rather than relying on the one INFRA provides. But again, this we can tackle at a later stage. Though at least now you can relate to my "INFRA fatigue". ;-P On Thu, Oct 12, 2023 at 6:16 PM Christian Grobmeier wrote: > > Hello, > > I made the Jekyll branch work with the staging environment: > https://logging.staged.apache.org/ > > When you change something in the sources, it will be automatically deployed > to Staging. > > We also have a "news section", aka blog: > https://logging.staged.apache.org/blog/ > > To add or change a project, you made want to edit: > https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml > You can edit it directly in Github UI if you prefer to try it out. > > It will take a few seconds to build and deploy. > > I want to move the Team members to a data file as well. > > If no objections, I'd like to move this to asf-site > > Kind regards, > Christian > > > On Tue, Oct 10, 2023, at 23:10, Christian Grobmeier wrote: > > Hello, > > > > Based on recent comments, I made a branch for using Jekyll on the > > leading site. It's a branch, we can discard it. The migration took me > > 1.5h, excluding this e-mail - not much wasted. > > > > https://github.com/apache/logging-site/tree/jekyll > > > > This is not yet auto-deployed, but if nobody opposes it, I will move > > on, merge, and autodeploy. > > > > Here is some info: > > > > Jekyll supports data files like this: > > https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml > > > > In the future, one could modify those data files directly from GitHub > > UI to update a status or a team member. It would be autodeployed then. > > The code for the output is also simple: > > > > https://github.com/apache/logging-site/blob/jekyll/index.html > > > > The amount of HTML has decreased. In addition, I was able to use > > Flexbox, which is built-in to browsers (no more slow Bootstrap in this > > case) > > > > We also can make use of SCSS now, which can use advanced CSS (in this > > case only nesting): > > https://github.com/apache/logging-site/blob/jekyll/css/site.scss#L44 > > > > The current team list could be moved to a data file, too, but I left it > > as adoc to showcase that this Jekyll page can work with adoc as well: > > https://github.com/apache/logging-site/blob/jekyll/team-list.adoc > > > > If you want to work with Jekyll, you can run the scripts: > > > > ./run-docker-build.sh (only one time; Docker needs to be installed) > > ./run-jekyll.sh (when you want to work) > > > > This way, you can build locally and check. However, you don't need to > > do this to update tiny things quickly. > > > > Please let me know if you want to object; otherwise, I would love to > > move this forward. > > > > If we, at some later point in time, move on to something like Antora, I > > will gladly help to migrate; however, since we are using adoc for this > > website as well, it should be straightforward. > > > > As soon as I have a go for this, I will prepare a blog section > > announcing the latest releases and preparing everything for some > > announcements we had in mind on the PMC list. > > > > Kind regards, > > Christian
Re: [PR] Bump com.github.spotbugs:spotbugs-annotations from 4.7.3 to 4.8.0 [logging-log4j-jmx-gui]
vy merged PR #1: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: Staging website (was: [VOTE] Release Apache Log4j 2.21.0)
Hi Christian, On Fri, 13 Oct 2023 at 13:46, Christian Grobmeier wrote: > Why is content not causing this issue? > For me both is possible, just trying to understand the best way. >From what I understand, if a branch (in any repo) has a configuration: staging: whoami: name_of_the_branch profile: subdir: INFRA copies the content of the branch into of a directory served by Apache HTTPD. Our current merged site should look like: content/log4jphp/...Log4j PHP stuff... output/...Jekyll stuff... When this is done a script determines which folder is the document root for the server. Since we have both `content` and `output` the script probably fails (I don't see neither Log4PHP nor your Jekyll stuff). Piotr
Re: [site] Jekyll proposal (in branch)
I am getting a 404 trying to access https://logging.staged.apache.org. Ralph > On Oct 12, 2023, at 9:16 AM, Christian Grobmeier wrote: > > Hello, > > I made the Jekyll branch work with the staging environment: > https://logging.staged.apache.org/ > > When you change something in the sources, it will be automatically deployed > to Staging. > > We also have a "news section", aka blog: > https://logging.staged.apache.org/blog/ > > To add or change a project, you made want to edit: > https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml > You can edit it directly in Github UI if you prefer to try it out. > > It will take a few seconds to build and deploy. > > I want to move the Team members to a data file as well. > > If no objections, I'd like to move this to asf-site > > Kind regards, > Christian > > > On Tue, Oct 10, 2023, at 23:10, Christian Grobmeier wrote: >> Hello, >> >> Based on recent comments, I made a branch for using Jekyll on the >> leading site. It's a branch, we can discard it. The migration took me >> 1.5h, excluding this e-mail - not much wasted. >> >> https://github.com/apache/logging-site/tree/jekyll >> >> This is not yet auto-deployed, but if nobody opposes it, I will move >> on, merge, and autodeploy. >> >> Here is some info: >> >> Jekyll supports data files like this: >> https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml >> >> In the future, one could modify those data files directly from GitHub >> UI to update a status or a team member. It would be autodeployed then. >> The code for the output is also simple: >> >> https://github.com/apache/logging-site/blob/jekyll/index.html >> >> The amount of HTML has decreased. In addition, I was able to use >> Flexbox, which is built-in to browsers (no more slow Bootstrap in this >> case) >> >> We also can make use of SCSS now, which can use advanced CSS (in this >> case only nesting): >> https://github.com/apache/logging-site/blob/jekyll/css/site.scss#L44 >> >> The current team list could be moved to a data file, too, but I left it >> as adoc to showcase that this Jekyll page can work with adoc as well: >> https://github.com/apache/logging-site/blob/jekyll/team-list.adoc >> >> If you want to work with Jekyll, you can run the scripts: >> >> ./run-docker-build.sh (only one time; Docker needs to be installed) >> ./run-jekyll.sh (when you want to work) >> >> This way, you can build locally and check. However, you don't need to >> do this to update tiny things quickly. >> >> Please let me know if you want to object; otherwise, I would love to >> move this forward. >> >> If we, at some later point in time, move on to something like Antora, I >> will gladly help to migrate; however, since we are using adoc for this >> website as well, it should be straightforward. >> >> As soon as I have a go for this, I will prepare a blog section >> announcing the latest releases and preparing everything for some >> announcements we had in mind on the PMC list. >> >> Kind regards, >> Christian
Re: Staging website (was: [VOTE] Release Apache Log4j 2.21.0)
I get a 404 trying to access the log4j2 staging web site. Although technically not required for a release I am not comfortable voting for the release without being able to see the web site. Ralph > On Oct 13, 2023, at 6:46 AM, Piotr P. Karwasz wrote: > > Hi Christian, > > On Fri, 13 Oct 2023 at 13:46, Christian Grobmeier > wrote: >> Why is content not causing this issue? >> For me both is possible, just trying to understand the best way. > > From what I understand, if a branch (in any repo) has a configuration: > > staging: > whoami: name_of_the_branch > profile: > subdir: > > INFRA copies the content of the branch into of a directory > served by Apache HTTPD. Our current merged site should look like: > > content/log4jphp/...Log4j PHP stuff... > output/...Jekyll stuff... > > When this is done a script determines which folder is the document > root for the server. Since we have both `content` and `output` the > script probably fails (I don't see neither Log4PHP nor your Jekyll > stuff). > > Piotr
Re: Staging website (was: [VOTE] Release Apache Log4j 2.21.0)
Nevermind. I was using the wrong url. Ralph > On Oct 13, 2023, at 8:21 AM, Ralph Goers wrote: > > I get a 404 trying to access the log4j2 staging web site. Although > technically not required for a release I am not comfortable voting for the > release without being able to see the web site. > > Ralph > >> On Oct 13, 2023, at 6:46 AM, Piotr P. Karwasz >> wrote: >> >> Hi Christian, >> >> On Fri, 13 Oct 2023 at 13:46, Christian Grobmeier >> wrote: >>> Why is content not causing this issue? >>> For me both is possible, just trying to understand the best way. >> >> From what I understand, if a branch (in any repo) has a configuration: >> >> staging: >> whoami: name_of_the_branch >> profile: >> subdir: >> >> INFRA copies the content of the branch into of a directory >> served by Apache HTTPD. Our current merged site should look like: >> >> content/log4jphp/...Log4j PHP stuff... >> output/...Jekyll stuff... >> >> When this is done a script determines which folder is the document >> root for the server. Since we have both `content` and `output` the >> script probably fails (I don't see neither Log4PHP nor your Jekyll >> stuff). >> >> Piotr >
Re: [chainsaw] What is necessary for a 2.2 release?
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).
> >> >>>
> >> >>> 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/5ccb3c8e55dffd4361c549c3bcd
Re: [chainsaw] What is necessary for a 2.2 release?
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). >> >> >>> >> >> >>> 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.
