Re: Removal of `log4j-jcl` in `3.x`

[Volkan Yazıcı]

+1

Piotr, you populated #2163
 tasks last week and
there asked to port `log4j-jcl` changes from `2.x` to `main`. That is
what I spent my yesterday with. I would appreciate it if you can share
these kinds of developments earlier. Putting that aside, thanks for
following up on `log4j-jcl` and I think it is good that we can drop it.

On Wed, Jan 10, 2024 at 11:11 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> Since `commons-logging` 1.3.0 was published last month and it supports
> Log4j API out-of-the-box, does it still make sense to keep `log4j-jcl`
> around in 3.x?
>
> I would keep the 2.x version, so that users don't need to modify their
> stacks. However we might assume that 3.x adopters are already running
> the latest versions of the remaining dependencies, specifically they
> upgraded `commons-logging`. This is why I would propose to remove
> `log4j-jcl` from 3.x.
>
> Remark that Spring users have been using `spring-jcl` for a very long
> time (which also supports the Log4j API), so they didn't need
> `log4j-jcl` either.
>
> Piotr
>

[VOTE][LAZY] Release Apache Logging Parent 10.6.0 RC1

[Piotr P. Karwasz]

This is a lazy-vote to release the Apache Logging Parent 10.6.0.

Website: https://logging.staged.apache.org/logging-parent
GitHub: https://github.com/apache/logging-parent
Commit: 64ae84e05803f3ab6d4201512b00f1cb1c4051e8
Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1256
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.

=== 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/dist/dev/logging/logging-parent
&& 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/repositories/orgapachelogging-1256
sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO

=== Release notes


This minor release contains several small changes to the build pipeline.

Most notably it bans wildcard imports from source code, which will
require expanding those imports before upgrading `logging-parent`.


 Added

* Add JSpecify to dependency management. (#88)
* Add enforcer rule to ban wildcard imports. All imports must be
expanded to provide better comparison of branches. (#63)

 Changed

* Merge Dependabot PRs instead of closing them. (#82)
* Disable 
https://bnd.bndtools.org/instructions/jpms-multi-release.html[`-jpms-multi-release`]
BND option. (#93)
* Clean up residual `module-info.class` before compilation. (#90)

 Updated

* Update `com.google.errorprone:error_prone_core` to version `2.24.1` (#89)
* Update `github/codeql-action` to version `3.23.0` (#91)
* Update `org.apache.rat:apache-rat-plugin` to version `0.16` (#92)

[log4j] ProGuard support in `log4j-api`

[Volkan Yazıcı]

ProGuard  – a GPL2-licensed,
widely used JAR optimizer and obfuscator in the Android world – doesn't
work with `log4j-api` out of the box. In summary, since Log4j uses
reflection, ProGuard needs to be configured to avoid removing certain Log4j
classes. A user has submitted (#2182)
 the ProGuard
configuration addressing the issue. We can either distribute it in
`META-INF/proguard/log4j.pro` and make `log4j-api` work out-of-the-box with
ProGoard or simply document this. Given how certain PMC members are
strongly allergic to breaking backward compatibility even in major
releases, I am afraid distributing this as a part of `log4j-api` will
become a liability we cannot get rid of in our lifetime. I will share this
with the user and ask him to convert his PR to a documentation update. If
you disagree, please let me know.

Re: [log4j] ProGuard support in `log4j-api`

[Ralph Goers]

Yeah - if we add it to the code base that implies that we are testing it. I 
really don’t want to be in the position where we start adding customizations 
for every tool a user might be using. This is very much in line with our not 
wanting to keep adding more and more integrations .

Ralph

> On Jan 11, 2024, at 11:36 AM, Volkan Yazıcı  wrote:
> 
> ProGuard  – a GPL2-licensed,
> widely used JAR optimizer and obfuscator in the Android world – doesn't
> work with `log4j-api` out of the box. In summary, since Log4j uses
> reflection, ProGuard needs to be configured to avoid removing certain Log4j
> classes. A user has submitted (#2182)
>  the ProGuard
> configuration addressing the issue. We can either distribute it in
> `META-INF/proguard/log4j.pro` and make `log4j-api` work out-of-the-box with
> ProGoard or simply document this. Given how certain PMC members are
> strongly allergic to breaking backward compatibility even in major
> releases, I am afraid distributing this as a part of `log4j-api` will
> become a liability we cannot get rid of in our lifetime. I will share this
> with the user and ask him to convert his PR to a documentation update. If
> you disagree, please let me know.

Re: Spring 3 and Log4j 3

[Ralph Goers]

On 2024/01/10 09:27:22 Volkan Yazıcı wrote:
> Thanks for chasing this Ralph, it is indeed a nice step forwards.
> 
> The aforementioned Log4j issue is fixed in #2062
> :
> 
>1. You submitted the PR on Dec 5 at 04:15 (GMT+1) and merged it at
>05:58. Next time, would you mind giving us a couple of days for the review,
>please?

AFAIK we are still doing CTR. Usually I would have just committed this directly 
but since we need something to track in the release notes I decided to create a 
PR.  If I had thought this to be anything more than a straightforward bug fix I 
would have asked for a review and waited.

>2. Piotr and I both reviewed the changes and we had remarks. None of
>them have been addressed so far. Would you mind responding to them, please?
>(See the PR for the comments.)

Sure. I apologize that I didn't notice the remarks due to the sheer volume of 
email I get from GitHub.

>3. Could you backport the fix to `2.x` branch too, please?

I could. I am still debating whether we should. It still isn't clear to me how 
much more has to be done to release 3.0.0. Once that is out we should be 
encouraging Spring 3.x users to upgrade to Log4j 3.

Ralph

Re: [log4j] ProGuard support in `log4j-api`

[Gary Gregory]

It feels wrong to add support for a special development time tool in our
runtime.

Gary

On Thu, Jan 11, 2024, 1:58 PM Ralph Goers 
wrote:

> Yeah - if we add it to the code base that implies that we are testing it.
> I really don’t want to be in the position where we start adding
> customizations for every tool a user might be using. This is very much in
> line with our not wanting to keep adding more and more integrations .
>
> Ralph
>
> > On Jan 11, 2024, at 11:36 AM, Volkan Yazıcı  wrote:
> >
> > ProGuard  – a GPL2-licensed,
> > widely used JAR optimizer and obfuscator in the Android world – doesn't
> > work with `log4j-api` out of the box. In summary, since Log4j uses
> > reflection, ProGuard needs to be configured to avoid removing certain
> Log4j
> > classes. A user has submitted (#2182)
> >  the ProGuard
> > configuration addressing the issue. We can either distribute it in
> > `META-INF/proguard/log4j.pro` and make `log4j-api` work out-of-the-box
> with
> > ProGoard or simply document this. Given how certain PMC members are
> > strongly allergic to breaking backward compatibility even in major
> > releases, I am afraid distributing this as a part of `log4j-api` will
> > become a liability we cannot get rid of in our lifetime. I will share
> this
> > with the user and ask him to convert his PR to a documentation update. If
> > you disagree, please let me know.
>
>