Re: A logger config named "root"
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"
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"
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"
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"
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"
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"
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 > >
