[RESULT][VOTE] Release Apache Log4j Scala 13.1.0

[Volkan Yazıcı]

Adding my +1.

With that, the release passes with 3 binding +1 votes from Piotr,
Christian, and me. I will continue the release process.

On Thu, Feb 1, 2024 at 11:31 AM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Log4j Scala 13.1.0.
>
> Website: https://logging.staged.apache.org/log4j/scala
> GitHub: https://github.com/apache/logging-log4j-scala
> Commit: abf3b13d3692b45d221dc78202c34f00f8f9124f
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-scala
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1257
> 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
>
> As was the case in the previous `13.0.0` release, the
> `log4j-api-scala_3.jar` artifact targeting Scala 3 in this
> release is also not reproducible due to a bug in the
> Scala 3 compiler. See `13.0.0` vote email[1] for details
> and how to verify the reproducibility by working around
> the Scala 3 compiler issue.
>
> [1] https://lists.apache.org/thread/3rrg3xj2sk6m3chx82k8kpx6nbdqb8oz
>
> === Review kit
>
> The minimum set of steps needed to review the uploaded distribution
> files in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> svn co https://dist.apache.org/repos/... && cd $_
>
> # Verify checksums
> shasum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> for sigFile in *.asc; do gpg --verify $sigFile; done
>
> # Verify reproduciblity
> umask 0022
> unzip *-src.zip -d src
> cd src
> export NEXUS_REPO=https://repository.apache.org/content/...
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
>
> === Release notes
>
> This minor release contains a bug fix, Software Bill of Materials
> (SBOM) generation, and some dependency updates.
>
>  Added
>
> * Start generating CycloneDX SBOM
>
>  Fixed
>
> * Fix recursive inlining issues in Scala 3 macros (#40)
>
>  Updated
>
> * Update `org.apache.logging.log4j:log4j-bom` to version `2.22.1` (#43)
> * Update `org.apache.logging:logging-parent` to version `10.6.0` (#44)

[ANNOUNCE] Apache Log4j Scala 13.1.0 released

[Volkan Yazıcı]

Apache Log4j Scala team is pleased to announce the 13.1.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

This minor release contains a bug fix, Software Bill of Materials
(SBOM) generation, and some dependency updates.

 Added

* Start generating CycloneDX SBOM

 Fixed

* Fix recursive inlining issues in Scala 3 macros (#40)

 Updated

* Update `org.apache.logging.log4j:log4j-bom` to version `2.22.1` (#43)
* Update `org.apache.logging:logging-parent` to version `10.6.0` (#44)

Re: Revamp of asynchronous logging

[Piotr P. Karwasz]

Hi Matt,

On Mon, 5 Feb 2024 at 22:37, Matt Sicker  wrote:
>
> For #3, I agree that we should perform formatting on the application thread 
> before transferring control to an asynchronous thread.

I am not sure if we always need to format the message (the
`log4j2.formatMsgAsync` property and and the
`@AsynchronouslyFormattable` on a message class might still be
useful), but for simplicity I would do it in a single place, just
before appending a log event to a queue or ring buffer.

Whether or not format messages synchronously should probably be
configurable (even for `@AsynchronouslyFormattable`): this speeds up
enabled loggers considerably (we might even think about pre-formatting
events), but slows down disabled loggers.

Piotr

Re: [log4j] Nested logging and async. message formatting

[Volkan Yazıcı]

Thanks so much for thinking along with me Piotr in this pretty
sophisticated puzzler. Regarding your following statements...

On Mon, Feb 5, 2024 at 8:43 PM Piotr P. Karwasz  wrote:
> I would prefer for the two event factories **not** to call
> `Message#getFormattedMessage` at all.
> ...
> Both issues are caused by an additional
> `InternalAsyncUtil.makeMessageImmutable()` in
> `MutableLogEvent#setMessage`, that can be removed.

I don't feel comfortable enough with the async. code base to carry out
these two changes. Nevertheless, I am all in for them. I don't know if
I can spare more time on this to examine it further and implement the
necessary changes. If you would like to go ahead yourself, you are
more than welcome.

For now, I will only remove `*Nested*Test` classes blocking the
`2.x-StatusLogger-revamp` branch.

Clean site repo

[Piotr P. Karwasz]

Hi all,

The current `asf-site` branch of the `logging-log4j-site` repo has
about 450k files, which makes it very hard to work on it.

Most of those are websites of old releases that I doubt anybody
(except search engines) visits. Those websites also pollute search
engine results: several times I found the page of an old release
better ranked that the current version.

Therefore I created a new branch `clean-log4j`[1] (which is published
as [2]) that contains only these directories:

* 1.x: last 1.x release.
* 2.3: last 2.3 release. Although not strictly necessary, I thought
that people stuck with Java 6 will appreciate a website without all
the features from newer releases.
* 2.12: last 2.12 release.
* 2.x: latest 2.x release.
* 3.x: latest 3.x release.
* extras: last Apache Log4j Extras release.

and the XML schemata for our changelog format (although they should be
moved to `/xml/ns/changelog`).

All the `log4j-` and similar directories are redirected
(permanent 301 redirect) to one of the remaining one: e.g.
`log4j-2.0.1` is redirected to `2.3`, `log4j-2.4` is redirected to
`2.12`, while `2.13.0` (sic!) is redirected to `2.x`.

For those that like to go down memory lane, the branch contains 65
commits for each one of our releases.

What do you think about replacing `asf-site` with this branch?

Piotr

[1] https://github.com/apache/logging-log4j-site/tree/clean-staging
[2] https://logging-clean.staged.apache.org/log4j

Re: Clean site repo

[Ralph Goers]

When you say “hard to work with it” what does that mean? All that should ever 
be required is to do 

git rebase asf-staging

I have never had that take more than a few seconds.

Are you really saying that the staging site is hard to work with?  My 
understanding is that “we” are working on reworking the web site. Volkan has 
mentioned some ideas to me which would allow us to keep the relevant info from 
previous releases.

I don’t like the idea of having multiple efforts going on.

Ralph

> On Feb 6, 2024, at 9:05 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> The current `asf-site` branch of the `logging-log4j-site` repo has
> about 450k files, which makes it very hard to work on it.
> 
> Most of those are websites of old releases that I doubt anybody
> (except search engines) visits. Those websites also pollute search
> engine results: several times I found the page of an old release
> better ranked that the current version.
> 
> Therefore I created a new branch `clean-log4j`[1] (which is published
> as [2]) that contains only these directories:
> 
> * 1.x: last 1.x release.
> * 2.3: last 2.3 release. Although not strictly necessary, I thought
> that people stuck with Java 6 will appreciate a website without all
> the features from newer releases.
> * 2.12: last 2.12 release.
> * 2.x: latest 2.x release.
> * 3.x: latest 3.x release.
> * extras: last Apache Log4j Extras release.
> 
> and the XML schemata for our changelog format (although they should be
> moved to `/xml/ns/changelog`).
> 
> All the `log4j-` and similar directories are redirected
> (permanent 301 redirect) to one of the remaining one: e.g.
> `log4j-2.0.1` is redirected to `2.3`, `log4j-2.4` is redirected to
> `2.12`, while `2.13.0` (sic!) is redirected to `2.x`.
> 
> For those that like to go down memory lane, the branch contains 65
> commits for each one of our releases.
> 
> What do you think about replacing `asf-site` with this branch?
> 
> Piotr
> 
> [1] https://github.com/apache/logging-log4j-site/tree/clean-staging
> [2] https://logging-clean.staged.apache.org/log4j

Re: Clean site repo

[Piotr P. Karwasz]

Hi Ralph,

On Tue, 6 Feb 2024 at 17:47, Ralph Goers  wrote:
>
> When you say “hard to work with it” what does that mean? All that should ever 
> be required is to do

I am mostly concerned by the great amount of files on the website.
Most of them are hidden, since we don't provide links to
`/log4j/log4j-2.18.0` anywhere our website.

This website cleanup should be in line with the (general)
reorganisation of the website proposed by Volkan: each major version
has its own folder. The git history only follows changes between
releases.

The main difference between the current organisation and the
`clean-log4j` branch is that you can look at differences using `git
diff` instead of `diff`.

Piot

[chainsaw] Status change?

[Christian Grobmeier]

Hello

we have had Chainsaw for a long time in our product list, and I can totally see 
that some - myself included - are emotionally attached to it. However, due to 
my work on it, I have given it some additional thought.

After working with the Chainsaw code base for a while, I saw that many features 
were commented out and removed when migrating to Log4j 2. 

Some basic features, such as "Open Logfile to view it directly." were removed. 
It is already hard to recover the functionality since log4j-extras no longer 
exists. In addition, as I learned recently, Log4j 2 has removed the XML 
Formatter. The old implementation of Chainsaw could only open XML-formatted log 
files.

Honestly, there is much work to make Chainsaw a working product again. I mostly 
did refactorings and clean-ups, but I am not even through. I could continue 
like this for two more months.

Restoring the old functionality and making it functional again requires even 
more months. 
If we had completed it, we would have restored a Swing application, mostly 
replaced by Kibana stacks.

At this point, I don't see how we can write the tons of code necessary, and 
also not how useful it would be. Either all our users are using Log4j 1, or we 
don't have any users at all for Chainsaw, since it didn't work.

For that reason, I would like to propose to move Chainsaw to dormant. If we 
feel for it, we can work and fix it - we should not archive the repo. But I 
would like to make clear that Chainsaw is not in good shape, and people should 
only use it only "at their own risk."

I would like to make clear that this proposal is not something I say easily, 
but I feel it is in the best interest of our users to communicate how we 
currently see the status of this project.

Please note, that I don't have much time to continue to work on it in the next 
months. 

Remembering the last discussion about this: Scott, are you OK with that move? I 
know it's your baby, but as long as we don't have a working product, we should 
move it. I am open to moving it back when we somehow get rid of all the 
problems.

Please let me know if one of you has an alternate proposal - we can also 
discuss it in the next call.

Kind regards,
Christian

--
The Apache Software Foundation
V.P., Data Privacy

Re: [chainsaw] Status change?

[Scott Deboy]

Thank you for spending time working on it Christian.

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

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

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

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

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

+1

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

Scott


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

Re: [chainsaw] Status change?

[Volkan Yazıcı]

+1

Allow me to make some corrections:

`XmlLayout` is dropped in Log4j 3, not in Log4j 2.

Logstash (the L in the ELK, Elasticsearch-Logstash-Kibana, stack) supports
reading logs from a file formatted using a particular pattern. You combine
Filebeat with grok filter

to achieve that.


On Wed, Feb 7, 2024 at 5:19 AM Scott Deboy  wrote:

> Thank you for spending time working on it Christian.
>
> I started contributing to Chainsaw in 2003. I agree. It's time.
>
> The primary benefit of Chainsaw was its built-in support for real-time
> tailing of ssh-accessible pattern-layout based logs  - something
> Kibana doesn't support well, and something no-one ever really
> understood about it.
>
> It was always a dev-focused tool - it works great for local dev, and
> works in some prod envs, if you spend enough time to get the setup to
> work.
>
> There was no great reason to move off of the log41 deps really - they
> aren't used for anything other than parsing the patternlayout, but
> log4j1 is dead, so I get it.
>
> I use it for my work, and will continue to do so, but the
> chainsaw-with-log4j1-dep branch. I may revert master back to that,
> because why not.
>
> +1
>
> Thanks again for putting up with my persistence to try and make it
> useful to folks - I appreciate it  :)
>
> Scott
>
>
> On 2/6/24, Christian Grobmeier  wrote:
> > Hello
> >
> > we have had Chainsaw for a long time in our product list, and I can
> totally
> > see that some - myself included - are emotionally attached to it.
> However,
> > due to my work on it, I have given it some additional thought.
> >
> > After working with the Chainsaw code base for a while, I saw that many
> > features were commented out and removed when migrating to Log4j 2.
> >
> > Some basic features, such as "Open Logfile to view it directly." were
> > removed. It is already hard to recover the functionality since
> log4j-extras
> > no longer exists. In addition, as I learned recently, Log4j 2 has removed
> > the XML Formatter. The old implementation of Chainsaw could only open
> > XML-formatted log files.
> >
> > Honestly, there is much work to make Chainsaw a working product again. I
> > mostly did refactorings and clean-ups, but I am not even through. I could
> > continue like this for two more months.
> >
> > Restoring the old functionality and making it functional again requires
> even
> > more months.
> > If we had completed it, we would have restored a Swing application,
> mostly
> > replaced by Kibana stacks.
> >
> > At this point, I don't see how we can write the tons of code necessary,
> and
> > also not how useful it would be. Either all our users are using Log4j 1,
> or
> > we don't have any users at all for Chainsaw, since it didn't work.
> >
> > For that reason, I would like to propose to move Chainsaw to dormant. If
> we
> > feel for it, we can work and fix it - we should not archive the repo.
> But I
> > would like to make clear that Chainsaw is not in good shape, and people
> > should only use it only "at their own risk."
> >
> > I would like to make clear that this proposal is not something I say
> easily,
> > but I feel it is in the best interest of our users to communicate how we
> > currently see the status of this project.
> >
> > Please note, that I don't have much time to continue to work on it in the
> > next months.
> >
> > Remembering the last discussion about this: Scott, are you OK with that
> > move? I know it's your baby, but as long as we don't have a working
> product,
> > we should move it. I am open to moving it back when we somehow get rid of
> > all the problems.
> >
> > Please let me know if one of you has an alternate proposal - we can also
> > discuss it in the next call.
> >
> > Kind regards,
> > Christian
> >
> > --
> > The Apache Software Foundation
> > V.P., Data Privacy
> >
>