Re: A logger config named "root"

2024-11-19 Thread Gary D. Gregory
On 2024/11/19 18:06:23 "Piotr P. Karwasz" wrote:
> Hi Gary,
> 
> On 19.11.2024 17:50, Gary D. Gregory wrote:
> > It seems odd to have a logger name not supported in a configuration file 
> > but then support it programmatically. Did I misread your suggestion? If 
> > that's the case, then issuing a warning makes even more sense.
> 
> The `error` alias works perfectly in a configuration file. Try replacing 
> your `` configuration element with something like this:
> 
> 
>
> 

Now I'm the one confused ;-P Why are we talking about ``? Maybe it 
doesn't really matter...

> 
> > I don't want to not loose support for "root" (lower-case) in the Log4j 1 
> > configuration properties bridge since that's a documented feature in 1.x. I 
> > still have a product that uses 1.x style properties files, and converting 
> > converting our installed user's product files is not a task anyone wants to 
> > do (same for the files in our test suites).
> 
> I don't seem to understand, what does the Log4j 1 "root" logger have to 
> do with the Log4j Core 2 "root" logger configuration? Isn't the v1 
> configuration factory supposed to map the "root" logger to the "" logger?

Well, they use the exact same name: "root", but, I haven't looked at that code 
in a while. Are you saying that "root" in a 1.x will retain it's functionality? 
If yes, then good and we can close this part of the chat.

> 
> Anyway, your problems should be soon over, since I am actively working 
> on a tool to automatically convert logging configuration files. The 
> first part, which includes a basic API and read-write support for the 
> Log4j Core 2 XML, JSON, YAML and Log4j Core 3 Properties format is 
> already available in apache/logging-log4j-transform#142[1]. It also 
> provides read-only support for the Log4j Core 2 Properties format, but I 
> am not to eager to allow users to convert nice configuration files into 
> a bunch of properties.

Very nice.

> 
> My next step will be to add read-only support for the Log4j 1 Properties 
> and XML formats. I will probably start by copy-pasting your excellent 
> `o.a.l.builders` package from the Log4j 1 bridge[2] and adapt it to the 
> task at hand.

TY.

Gary

> 
> Piotr
> 
> [1] https://github.com/apache/logging-log4j-transform/pull/142
> 
> [2] 
> https://github.com/apache/logging-log4j2/tree/2.x/log4j-1.2-api/src/main/java/org/apache/log4j/builders
> 
> 


Re: A logger config named "root"

2024-11-19 Thread Piotr P. Karwasz

Hi Gary,

On 19.11.2024 17:50, Gary D. Gregory wrote:

It seems odd to have a logger name not supported in a configuration file but 
then support it programmatically. Did I misread your suggestion? If that's the 
case, then issuing a warning makes even more sense.


The `error` alias works perfectly in a configuration file. Try replacing 
your `` configuration element with something like this:



  



I don't want to not loose support for "root" (lower-case) in the Log4j 1 
configuration properties bridge since that's a documented feature in 1.x. I still have a 
product that uses 1.x style properties files, and converting converting our installed 
user's product files is not a task anyone wants to do (same for the files in our test 
suites).


I don't seem to understand, what does the Log4j 1 "root" logger have to 
do with the Log4j Core 2 "root" logger configuration? Isn't the v1 
configuration factory supposed to map the "root" logger to the "" logger?


Anyway, your problems should be soon over, since I am actively working 
on a tool to automatically convert logging configuration files. The 
first part, which includes a basic API and read-write support for the 
Log4j Core 2 XML, JSON, YAML and Log4j Core 3 Properties format is 
already available in apache/logging-log4j-transform#142[1]. It also 
provides read-only support for the Log4j Core 2 Properties format, but I 
am not to eager to allow users to convert nice configuration files into 
a bunch of properties.


My next step will be to add read-only support for the Log4j 1 Properties 
and XML formats. I will probably start by copy-pasting your excellent 
`o.a.l.builders` package from the Log4j 1 bridge[2] and adapt it to the 
task at hand.


Piotr

[1] https://github.com/apache/logging-log4j-transform/pull/142

[2] 
https://github.com/apache/logging-log4j2/tree/2.x/log4j-1.2-api/src/main/java/org/apache/log4j/builders




Re: A logger config named "root"

2024-11-19 Thread Tim Perry
How much code is it to support "root" fully? If this is trivial, fully
supporting "root" makes sense. If not, deprecating it makes sense. Heck, do
both! LOL.

On Tue, Nov 19, 2024 at 7:11 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On 19.11.2024 13:08, Gary Gregory wrote:
> > This seems like a nice clean up that will break a lot of configurations.
> >
> > How about we issue a warning in 2.x like "The logger name 'root' is
> > deprecated and will be removed in 3.0"?
>
> I thought about going in the other direction: allow users to call
> `Configurator.setLevel("ROOT", Level.INFO)`.
>
> It is unlikely that "ROOT" will collide with any real logger.
>
> Piotr
>
>


Re: A logger config named "root"

2024-11-19 Thread Piotr P. Karwasz

Hi Gary,

On 19.11.2024 13:08, Gary Gregory wrote:

This seems like a nice clean up that will break a lot of configurations.

How about we issue a warning in 2.x like "The logger name 'root' is
deprecated and will be removed in 3.0"?


I thought about going in the other direction: allow users to call 
`Configurator.setLevel("ROOT", Level.INFO)`.


It is unlikely that "ROOT" will collide with any real logger.

Piotr



A logger config named "root"

2024-11-19 Thread Piotr P. Karwasz

Hi all,

In Log4j Core 2 there is a residual support for a logger named "root", e.g.:



has the same effect as:



However `Configurator.setLevel()`, `Configuration.getLoggerConfig()` and 
other methods don't support the `root` alias. Should we introduce 
support for `root` to those methods or rather remove (in Log4j Core 3) 
the residual support in the `LoggerConfig` class?


Note that being able to refer to the root logger configuration via a 
non-empty string has its advantage: Kafka uses it for a REST API that 
allows users to modify the configured log levels.


Piotr

[1] 
https://github.com/apache/kafka/blob/efaab5132b71e2566cfb4e4644d6245f261f49d0/core/src/main/scala/kafka/utils/Log4jController.scala




Re: A logger config named "root"

2024-11-19 Thread Gary D. Gregory
Hi Piotr,

It seems odd to have a logger name not supported in a configuration file but 
then support it programmatically. Did I misread your suggestion? If that's the 
case, then issuing a warning makes even more sense.

I don't want to not loose support for "root" (lower-case) in the Log4j 1 
configuration properties bridge since that's a documented feature in 1.x. I 
still have a product that uses 1.x style properties files, and converting 
converting our installed user's product files is not a task anyone wants to do 
(same for the files in our test suites).

In summary:
- I still like the idea of a deprecation warning
- Don't break 1.x configuration files

HTH,
Gary

[1] https://logging.apache.org/log4j/1.x/manual.html

On 2024/11/19 15:10:50 "Piotr P. Karwasz" wrote:
> Hi Gary,
> 
> On 19.11.2024 13:08, Gary Gregory wrote:
> > This seems like a nice clean up that will break a lot of configurations.
> >
> > How about we issue a warning in 2.x like "The logger name 'root' is
> > deprecated and will be removed in 3.0"?
> 
> I thought about going in the other direction: allow users to call 
> `Configurator.setLevel("ROOT", Level.INFO)`.
> 
> It is unlikely that "ROOT" will collide with any real logger.
> 
> Piotr
> 
> 


Re: A logger config named "root"

2024-11-19 Thread Gary Gregory
This seems like a nice clean up that will break a lot of configurations.

How about we issue a warning in 2.x like "The logger name 'root' is
deprecated and will be removed in 3.0"?

Gary


On Tue, Nov 19, 2024, 7:01 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> In Log4j Core 2 there is a residual support for a logger named "root",
> e.g.:
>
> 
>
> has the same effect as:
>
> 
>
> However `Configurator.setLevel()`, `Configuration.getLoggerConfig()` and
> other methods don't support the `root` alias. Should we introduce
> support for `root` to those methods or rather remove (in Log4j Core 3)
> the residual support in the `LoggerConfig` class?
>
> Note that being able to refer to the root logger configuration via a
> non-empty string has its advantage: Kafka uses it for a REST API that
> allows users to modify the configured log levels.
>
> Piotr
>
> [1]
>
> https://github.com/apache/kafka/blob/efaab5132b71e2566cfb4e4644d6245f261f49d0/core/src/main/scala/kafka/utils/Log4jController.scala
>
>