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

Reply via email to