[Log4j] Moving `log4j-jmx-gui` to its own repo

[Volkan Yazıcı]

[TLDR: Piotr and I propose moving `log4j-jmx-gui` to its own repository to
ease Java 9+ migration for `2.x`, objections?]

In the `2.x` branch, AFAIK, `log4j-jmx-gui` is the only module that has a
Java 8 requirement, i.e., `jconsole.jar`. Piotr and I have been trying to
come up with ways to make `2.x` use a Java 9+ compiler (be it 11 or 17),
though every solution we have come up with has certain limitations due to
this `jconsole.jar` requirement. I want to propose moving `log4j-jmx-gui`
to its own repository.

For one, we _can_ simply remove it from `2.x` for the time being and
postpone the new repository bootstrapping until there is a need to make a
change to `log4j-jmx-gui`. (Please note that I mention this for its
implementation convenience, not as a requirement.)

Second, we _might_ break some users' workflow. Once the module is moved to
its own repository, it will have a separate release lifecycle, hence, we
should ideally remove it from `log4j-bom`. Users who run `log4j-jmx-gui`
through the dependency provided by `log4j-bom` will have a problem. Imagine
we release `log4j-bom` 2.21.0 that doesn't ship a `log4j-jmx-gui`
dependency. Piotr and I think that probably almost all `log4j-jmx-gui`
users provide an explicit version, hence our inclination for this breaking
change.

Objections?

Re: [Log4j] Moving `log4j-jmx-gui` to its own repo

[Apache]

I would be comfortable with this if it is moved to its own repo and released 
first, then removed from the Log4J repo. I am not comfortable with “we can do 
it someday if we want to” unless we are dropping support for it.

Ralph

> On Mar 20, 2023, at 3:36 AM, Volkan Yazıcı  wrote:
> 
> [TLDR: Piotr and I propose moving `log4j-jmx-gui` to its own repository to
> ease Java 9+ migration for `2.x`, objections?]
> 
> In the `2.x` branch, AFAIK, `log4j-jmx-gui` is the only module that has a
> Java 8 requirement, i.e., `jconsole.jar`. Piotr and I have been trying to
> come up with ways to make `2.x` use a Java 9+ compiler (be it 11 or 17),
> though every solution we have come up with has certain limitations due to
> this `jconsole.jar` requirement. I want to propose moving `log4j-jmx-gui`
> to its own repository.
> 
> For one, we _can_ simply remove it from `2.x` for the time being and
> postpone the new repository bootstrapping until there is a need to make a
> change to `log4j-jmx-gui`. (Please note that I mention this for its
> implementation convenience, not as a requirement.)
> 
> Second, we _might_ break some users' workflow. Once the module is moved to
> its own repository, it will have a separate release lifecycle, hence, we
> should ideally remove it from `log4j-bom`. Users who run `log4j-jmx-gui`
> through the dependency provided by `log4j-bom` will have a problem. Imagine
> we release `log4j-bom` 2.21.0 that doesn't ship a `log4j-jmx-gui`
> dependency. Piotr and I think that probably almost all `log4j-jmx-gui`
> users provide an explicit version, hence our inclination for this breaking
> change.
> 
> Objections?

RE: I have a question regarding LOG4NET-27 and LOG4NET-367.

[夏月 梨幸]

I do not speak English, so please excuse the machine translation.

Hello.
Thank you for your quick reply.

> There should be a branch containing the work in progress of the next 
> generation rolling file appender. 
> I named it something like RFA-NG if my memory does not fail on me. 
> You could base your work on that or proceed otherwise.

The path to proceed with implementation based on RFA-NG is the path to address 
all the bugs, right?　That is too much of a hurdle. 
I considered not touching the existing bug and addressing only LOG4NET-27, but 
the following comment on 2017/03/09 09:27 made me feel that path is also 
dangerous.

> https://log4net-user.logging.apache.narkive.com/tnI5OT7f/rolling-file-operation-failing-with-source-does-not-exist
> Please note that Stefan Bodewig and I agree that the existing 
> RollingFileAppender implementation is broken in too many ways to fix it.
> Patching it further could finally break the few things it does well and 
> therefore we avoid to patch it any further. 

Currently, it is hard to choose between the two, so we will give it more 
consideration.
BTW, I couldn't find RFA-NG (feature/RollingFileAppender-NG) on Git 
(https://github.com/apache/logging-log4net/branches).

> https://issues.apache.org/jira/projects/LOG4NET/issues/LOG4NET-367?filter=allopenissues
> Dominik Psenner added a comment - 19/May/17 19:56
> I just pushed the latest patch from 
> https://bitbucket.org/NachbarsLumpi/log4net-patches/src/tip/RFA-NG to a new 
> feature branch on the git repository named feature/RollingFileAppender-NG.
> However, this still needs a lot of work to be done and helping hands are 
> welcome!

Sorry for the inconvenience, but we would appreciate it if you could provide us 
with the URL.

Thank you for reading.

夏月 梨幸(Natsuki Rikou)

-Original Message-
From: Dominik Psenner  
Sent: Monday, March 20, 2023 1:26 AM
To: dev@logging.apache.org
Subject: Re: I have a question regarding LOG4NET-27 and LOG4NET-367.

Hi,

I am mostly no longer involved in software development, busy otherwise. It is 
great to see you are interested and willing to invest your valuable time.

There should be a branch containing the work in progress of the next generation 
rolling file appender. I named it something like RFA-NG if my memory does not 
fail on me. You could base your work on that or proceed otherwise.

Warm regards
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find them.

On Sun, Mar 19, 2023, 13:38 夏月 梨幸  wrote:

> I do not speak English, so please excuse the machine translation.
>
> Hello.
> Let me ask you a question.
>
> 1) Which is the best way to proceed on the topic of MaxDateRollBackups 
> in RollingFileAppender?
> ・post https://issues.apache.org/jira/browse/LOG4NET-27
> ・post https://issues.apache.org/jira/browse/LOG4NET-367
> ・post dev@logging.apache.org
>
> 2) Since RollingFileAppender has been suggested to be re-created in 
> LOG4NET-367, I am working on implementing MaxDateRollBackups as a 
> single function independent of Log4Net.
> We hoped that if we provided an API, the person leading 
> LOG4NET-367 would call it at the right time from the appropriate 
> method in RollingFileAppender.
>
> However, since Log4Net became dormant on 2020/04/05 and was 
> revived on 2020/04/06, we are not sure who is now in charge and leading 
> LOG4NET-367.
> Is Dominik Psenner still in charge of LOG4NET-367? Or is he giving 
> it up?
>
> 3) I am currently working on implementing MaxDateRollBackups in
> VisualStudio2022 with .NetFramework4.7, C# 7.0.
> However, I found the following statement.
>
> > apache-log4net-source-2.0.15.zip
> >   BUILDING.md
> >   Log4net provides support for a wide array of targets, including
> >   - older .net 2 and 3.5 (including client profiles)
> >   - more modern net40/net45
> >   - netstandard1.3/2.0
>
> Would I have had to implement it in .NetFramework 2.0, C# 2.0?
>
> That is all.
>
> Thank you for reading.
>
> 夏月 梨幸(Natsuki Rikou)
>
>

RE: [External] Re: Log4j Issue

[Gurumoorthi Vijayalingam]

Hi Team,

Can you please help us to fix this issue.

Regards,
Guru.

From: Dominik Psenner 
Sent: 04 March 2023 02:16
To: secur...@logging.apache.org
Cc: Paolo Gil Ostrea ; Roark Hamilton 
; Gurumoorthi Vijayalingam 
Subject: [External] Re: Log4j Issue

CAUTION: This message was sent from outside of the company. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe.

Hi

I'm CCing the original author of the message. Please read below. Further please 
consider posting to the proper mailing list. The request is not about a 
security issue and probably should have been posted to 
dev@logging.apache.org after subscribing to that 
mailing list.

Warm regards
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find them.

On Fri, Mar 3, 2023, 21:17 Piotr P. Karwasz 
mailto:piotr.karw...@gmail.com>> wrote:
Gurumoorthi,

On Fri, 3 Mar 2023 at 19:04, Gurumoorthi Vijayalingam
mailto:gvijayalin...@simeio.com>> wrote:
> Just attached the error message and log4j configuration for your reference.

MapLookup#newMap changed from private (as in 2.2) to package (as in
2.17.1) in the course of history. Your Tomcat is picking up the
private one, which means that log4j-core-2.2.jar is still on the
classpath.
Double check that the old Log4j2 version are no longer there and
restart Tomcat to be sure.

Piotr

Re: [Log4j] Moving `log4j-jmx-gui` to its own repo

[Piotr P. Karwasz]

Hi Ralph,

On Mon, 20 Mar 2023 at 15:09, Apache  wrote:
>
> I would be comfortable with this if it is moved to its own repo and released 
> first, then removed from the Log4J repo. I am not comfortable with “we can do 
> it someday if we want to” unless we are dropping support for it.

Can we keep 2.20.0 as current release and release a new version of
`log4j-jmx-gui` as soon as we fix some bug in it?

`log4j-bom` is also mainly independent from the rest of the modules,
so we can move it to a separate repo.

A Log4j2 release would technically consist of a release of `l-log4j2`
followed by a release of `l-l-bom` that bumps all versions (except
`log4j-jmx-gui`).

Piotr

Re: [Log4j] Moving `log4j-jmx-gui` to its own repo

[Ralph Goers]

That doesn’t really work:
1. As soon as there is some bug in it means someone has to go an create the 
repo and the appropriate scaffolding to get a release to work. No one will ever 
do it.
2. I release cannot consists of stuff from multiple repos. The distribution zip 
needs to contain everything in the release, which means the distribution module 
would have to be in the bom project. That saves me nothing when performing a 
release and makes it harder.

If you don’t want to support jmx-gui then propose we kill it.

Ralph

> On Mar 20, 2023, at 12:53 PM, Piotr P. Karwasz  
> wrote:
> 
> Hi Ralph,
> 
> On Mon, 20 Mar 2023 at 15:09, Apache  wrote:
>> 
>> I would be comfortable with this if it is moved to its own repo and released 
>> first, then removed from the Log4J repo. I am not comfortable with “we can 
>> do it someday if we want to” unless we are dropping support for it.
> 
> Can we keep 2.20.0 as current release and release a new version of
> `log4j-jmx-gui` as soon as we fix some bug in it?
> 
> `log4j-bom` is also mainly independent from the rest of the modules,
> so we can move it to a separate repo.
> 
> A Log4j2 release would technically consist of a release of `l-log4j2`
> followed by a release of `l-l-bom` that bumps all versions (except
> `log4j-jmx-gui`).
> 
> Piotr

Re: [External] Re: Log4j Issue

[Christian Grobmeier]

Hello Gurumoorthi,

Piotr already responded to your email:

> MapLookup#newMap changed from private (as in 2.2) to package (as in
> 2.17.1) in the course of history. Your Tomcat is picking up the
> private one, which means that log4j-core-2.2.jar is still on the
> classpath.
> Double check that the old Log4j2 version are no longer there and
> restart Tomcat to be sure.
>
> Piotr

If this information does not help you, respond to dev@logging.apache.org as 
Dominik told you.

Kind regards,
Christian


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

On Mon, Mar 20, 2023, at 17:27, Gurumoorthi Vijayalingam wrote:
> Hi Team,
>
> Can you please help us to fix this issue.
>
> Regards,
> Guru.
>
> From: Dominik Psenner 
> Sent: 04 March 2023 02:16
> To: secur...@logging.apache.org
> Cc: Paolo Gil Ostrea ; Roark Hamilton 
> ; Gurumoorthi Vijayalingam 
> 
> Subject: [External] Re: Log4j Issue
>
> CAUTION: This message was sent from outside of the company. Please do 
> not click links or open attachments unless you recognize the source of 
> this email and know the content is safe.
>
> Hi
>
> I'm CCing the original author of the message. Please read below. 
> Further please consider posting to the proper mailing list. The request 
> is not about a security issue and probably should have been posted to 
> dev@logging.apache.org after subscribing 
> to that mailing list.
>
> Warm regards
> Dominik
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find them.
>
> On Fri, Mar 3, 2023, 21:17 Piotr P. Karwasz 
> mailto:piotr.karw...@gmail.com>> wrote:
> Gurumoorthi,
>
> On Fri, 3 Mar 2023 at 19:04, Gurumoorthi Vijayalingam
> mailto:gvijayalin...@simeio.com>> wrote:
>> Just attached the error message and log4j configuration for your reference.
>
> MapLookup#newMap changed from private (as in 2.2) to package (as in
> 2.17.1) in the course of history. Your Tomcat is picking up the
> private one, which means that log4j-core-2.2.jar is still on the
> classpath.
> Double check that the old Log4j2 version are no longer there and
> restart Tomcat to be sure.
>
> Piotr