From the questions you posted up to now, you use a lot of custom code extending
Log4j 1.x capabilities. In my personal opinion you'll spend more time trying to
adapt your code to use the Log4j 1.x bridge, than it would require to migrate
to Log4j 2.x.
Almost everything is working in my application now except this "level" setting.
Please let me know if you have any idea how to fix this stuff.
-----Original Message-----
From: Piotr P. Karwasz <piotr.karw...@gmail.com>
Sent: Monday, March 7, 2022 7:29 PM
To: Log4J Users List <log4j-user@logging.apache.org>
Subject: Re: Log level settings are not working correctly and getting wrong
value
*** External email: Verify sender before opening attachments or links ***
Hello Pooja,
On Mon, Mar 7, 2022 at 1:40 PM Pooja Pandey <pooja.pan...@asg.com.invalid>
wrote:
>
> -> If I recall correctly, you are using a custom `Logger` class. My guess is
> that you overrode the `getEffectiveLevel()` with some custom logic.
>
> Yes Piotr, you are correct. I am overriding this method in my custom logger
> as below. Do you think this could be the problem??
>
> @Override
> public Level getEffectiveLevel() {
> Level configuredLevel = super.getEffectiveLevel();
> ...
> Level currLevel = myLevel.get();
> ...
> if (currLevel.isGreaterOrEqual(configuredLevel))
> return configuredLevel;
> return currLevel;
> }
That is your problem: your function is returning the smallest between
`configuredLevel` and your custom `currLevel` using Log4j 1.x semantics (i.e.
DEBUG is smaller than ERROR).
I think we are having an XY communication problem [1]: my guess is that your
legacy code overrode `getEffectiveLevel` to influence which messages will be
logged and which won't. That would work in Log4j 1.x, but the bridge has
different implementation details (look at the package private method
`Category#maybeLog` and the public `Category#forcedLog` filter the messages),
so even if you modify `getEffectiveLevel()`, it will have no effects on logging.
The Log4j 1.x bridge is not meant to provide binary compatibility for
applications that configure Log4j 1.x programmatically, its scope is limited to
the cases mentioned in the documentation[2]:
1. It assures binary compatibility for applications and libraries that use the
Log4j 1.x API. By Log4j 1.x API I mean the `Logger#error`, `Logger#warn` and
similar methods, 2. It allows users to continue using the Log4j 1.x
configuration format.
Although version 2.17.2 made a huge step forward towards a drop-in Log4j 1.x
replacement (mostly due to Gary), that is not among the component's goals.
From the questions you posted up to now, you use a lot of custom code extending
Log4j 1.x capabilities. In my personal opinion you'll spend more time trying to
adapt your code to use the Log4j 1.x bridge, than it would require to migrate
to Log4j 2.x.
Piotr
[1] https://en.wikipedia.org/wiki/XY_problem
[2] https://logging.apache.org/log4j/2.x/manual/migration.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
