[ANNOUNCE] Apache Log4j JMX GUI 2.21.0 released

[Volkan Yazıcı]

Apache Log4j JMX GUI[1] team is pleased to announce the 2.21.0
release. This project provides a Swing-based client for remotely
editing the Log4j configuration and remotely monitoring `StatusLogger`
output. It can be run as a standalone application or as a JConsole plugin.

# Release Notes

This marks the first release where the Log4j JMX GUI is released
separately from the Log4j itself.

## Changes

### Added

* Project is moved to a new repository[1] with its own release cycle

[1] https://github.com/apache/logging-log4j-jmx-gui

Re: Archiving `logging-log4j-server` and `-audit`

[Volkan Yazıcı]

Hey Gary,

I'd appreciate your response on this `dev@` thread. I am cleaning up all
repositories and trying to either (in order of preference)

   1. delete them (since they are practically empty or irrelevant)
   2. archive them (clearly communicate it to the users that nobody is
   working on these projects, they are not maintained, etc. the repository is
   there only for archival purposes. note the archival is a reversible
   operation.)
   3. modernize them (make `./mvnw clean verify` work flawlessly on
   multiple platforms, erect the CI, updated dependencies, setup `dependabot`,
   clean up `pom.xml`s, docs, `README.adoc`, etc.)

>From this point of view, we (Ralph, Piotr, and me) are in favor of
archiving `logging-log4j-server` and moving the `log4j-server` module to
`logging-log4j-samples`, which is completely modernized. Is that okay with
you?


On Thu, Sep 14, 2023 at 8:25 PM Volkan Yazıcı  wrote:

> Gary, you haven't replied to this question of mine yet. I'd like to
> know more about your use case.
>
> I had a call with Ralph and he stated `log4j-server` is not usable
> without customizations. Hence, he added, it is better suited to
> `log4j-samples`. I liked this idea. Do you have any objections if we
> archive the `log4j-server` and move its content to `log4j-samples`
> instead?
>
> On Wed, Sep 13, 2023 at 3:16 PM Volkan Yazıcı  wrote:
> >
> > The project doesn't have any releases, how do you use it at work? Note
> that once they are retired (i.e., archived) you will still have access to
> the sources.
> >
> > On Wed, Sep 13, 2023 at 3:06 PM Gary Gregory 
> wrote:
> >>
> >> Yes, we use logging-log4j-server at work.
> >>
> >> Gary
> >>
> >> On Wed, Sep 13, 2023 at 8:15 AM Volkan Yazıcı  wrote:
> >> >
> >> > I propose retiring `logging-log4j-server`
> >> >  and
> `logging-log4j-audit`
> >> >  repositories (which
> never
> >> > had any releases) and making it clear in their READMEs that these
> >> > repositories exist only for archival purposes. Objections?
>

Parallel test execution

[Piotr P. Karwasz]

Hi all,

I plan to merge PR #1785[1] soon, which should decrease by 50% the
time we spend waiting for the CI to succeed. This PR switches the
default Surefire mode to running 1C tests in parallel each in its own
JVM (where C is the number of cores available). The order of execution
is deterministic (alphabetical)

In order to run tests sequentially use: -Psequential-tests,

In order to run tests in a random order use: -Dsurefire.runOrder=random

Remark that most of the tests were not written with parallel execution
in mind and we'll probably never have time to fix them. Therefore
we'll probably never be able to run everything in a single JVM, but
spawning JVMs seems rather fast these days (0.5-1 sec per test).

Piotr

[1] https://github.com/apache/logging-log4j2/pull/1785

Re: Parallel test execution

[Matt Sicker]

This sounds like a great improvement! As for the single JVM idea, perhaps if we 
add tags to tests that require a clean JVM, then we’d be able to run some 
subset of tests faster.

> On Sep 18, 2023, at 3:42 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> I plan to merge PR #1785[1] soon, which should decrease by 50% the
> time we spend waiting for the CI to succeed. This PR switches the
> default Surefire mode to running 1C tests in parallel each in its own
> JVM (where C is the number of cores available). The order of execution
> is deterministic (alphabetical)
> 
> In order to run tests sequentially use: -Psequential-tests,
> 
> In order to run tests in a random order use: -Dsurefire.runOrder=random
> 
> Remark that most of the tests were not written with parallel execution
> in mind and we'll probably never have time to fix them. Therefore
> we'll probably never be able to run everything in a single JVM, but
> spawning JVMs seems rather fast these days (0.5-1 sec per test).
> 
> Piotr
> 
> [1] https://github.com/apache/logging-log4j2/pull/1785

Re: Archive `logging-pipelines`

[Matt Sicker]

Should be fine to archive as we’re migrated to GHA.

> On Sep 15, 2023, at 2:03 AM, Volkan Yazıcı  wrote:
> 
> AFAIC, no Logging Services projects use Jenkins pipelines anymore.
> Created INFRA-24991 to archive the `logging-pipelines` repository,
> FYI.

Re: [log4j-kotlin] 1.3.0 release rampdown

[Matt Sicker]

Sounds good to me! Might want to re-sync the Log4j version to the latest 
release, though.

> On Sep 15, 2023, at 8:00 AM, Volkan Yazıcı  wrote:
> 
> I renovated `log4j-kotlin` quite a bit and I think we are ready for
> the `1.3.0` release. I share the tentative release notes below to give
> you an idea. Are there anything else you want to incorporate into this
> release?
> 
> ### Added
> 
> * Added an extension property for storing a cached logger (#29)
> * Added facade APIs for manipulating the context map and stack (#30)
> * Added missing `catching` and `throwing` API methods in `KotlinLogger` (#32)
> 
> ### Changed
> 
> * Updated Log4j dependency to `2.20.0`
> * Bumped `logging-parent` version to `10.0.0` and overhauled the
> entire project infrastructure to take advantage of its goodies (#37)
> * Migrated tests to JUnit 5
> * Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4`
> respectively