You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Pooja Pandey <Po...@asg.com.INVALID> on 2022/03/07 10:23:28 UTC
Log level settings are not working correctly and getting wrong value
Hi team,
I think there is something wrong with Log4j1.x bridge level handling when migrating from log4j1.x to log4j2.x.
Issue: In my config file, log level is set to "Error", but with log4j1.x bridge log level is getting calculated as DEBUG. I think this is since in log4j1.x from FATAL to DEBUG level integer value decreases as shown below but in log4j2.x from FATAL to DEBUG integer value increases as shown below.
I think there is some issue in getEffectiveLevel(). Please let me know if you have any idea on this.
Config
Log4j1.x
Log4j2.x
Level integer value
/**
* The <code>OFF</code> has the highest possible rank and is
* intended to turn off logging.
*/
public static final int OFF_INT = Integer.MAX_VALUE;
/**
* The <code>FATAL</code> level designates very severe error
* events that will presumably lead the application to abort.
*/
public static final int FATAL_INT = 50000;
/**
* The <code>ERROR</code> level designates error events that
* might still allow the application to continue running.
*/
public static final int ERROR_INT = 40000;
/**
* The <code>WARN</code> level designates potentially harmful situations.
*/
public static final int WARN_INT = 30000;
/**
* The <code>INFO</code> level designates informational messages
* that highlight the progress of the application at coarse-grained
* level.
*/
public static final int INFO_INT = 20000;
/**
* The <code>DEBUG</code> Level designates fine-grained
* informational events that are most useful to debug an
* application.
*/
public static final int DEBUG_INT = 10000;
//public final static int FINE_INT = DEBUG_INT;
/**
* The <code>ALL</code> has the lowest possible rank and is intended to
* turn on all logging.
*/
public static final int ALL_INT = Integer.MIN_VALUE;
* OFF(0) //No events will be logged.
* FATAL(100) //A severe error that will prevent the application from continuing.
* ERROR(200) //An error in the application, possibly recoverable.
* WARN(300) //An event that might possible lead to an error.
* INFO(400) //An event for informational purposes.
* DEBUG(500) //A general debugging event.
* TRACE(600) //A fine-grained debug message, typically capturing the flow through the application.
* ALL(Integer.MAX_VALUE) //All events should be logged.
*
* Typically, configuring a level in a filter or on a logger will cause logging
* events of that level and those that are more specific to pass through the filter.
* A special level, ALL, is guaranteed to capture all levels when used in logging
* configurations.
*
* FATAL is defined in class StandardLevel.
*/
Re: Log level settings are not working correctly and getting wrong value
Posted by Pooja Pandey <Po...@asg.com.INVALID>.
Thank you so much Piotr 👍👍
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Piotr P. Karwasz <pi...@gmail.com>
Sent: Monday, March 7, 2022 11:58:14 PM
To: Log4J Users List <lo...@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,
On Mon, Mar 7, 2022 at 3:15 PM Pooja Pandey
<Po...@asg.com.invalid> wrote:
>
> 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.
Since you want to log messages that are less specific than the level
in the configuration file **or** less specific that a custom level you
set up programmatically, you should look into the global filter:
https://logging.apache.org/log4j/2.x/manual/filters.html
From the documentation: "Events that are rejected by these filters
will not be passed to loggers for further processing. Once an event
has been accepted by a Context-wide filter it will not be evaluated by
any other Context-wide Filters nor will the Logger's Level be used to
filter the event. " The `Filter` interface [1] has many methods, but
if I am not wrong, you are interested in the `filter(Logger, Level,
Object, Throwable)` method. You can extend `AbstractFilter` for a
default implementation of the remaining methods.
[1] https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/Filter.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log level settings are not working correctly and getting wrong value
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hello,
On Mon, Mar 7, 2022 at 3:15 PM Pooja Pandey
<Po...@asg.com.invalid> wrote:
>
> 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.
Since you want to log messages that are less specific than the level
in the configuration file **or** less specific that a custom level you
set up programmatically, you should look into the global filter:
https://logging.apache.org/log4j/2.x/manual/filters.html
From the documentation: "Events that are rejected by these filters
will not be passed to loggers for further processing. Once an event
has been accepted by a Context-wide filter it will not be evaluated by
any other Context-wide Filters nor will the Logger's Level be used to
filter the event. " The `Filter` interface [1] has many methods, but
if I am not wrong, you are interested in the `filter(Logger, Level,
Object, Throwable)` method. You can extend `AbstractFilter` for a
default implementation of the remaining methods.
[1] https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/Filter.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Log level settings are not working correctly and getting wrong value
Posted by Pooja Pandey <Po...@asg.com.INVALID>.
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 <pi...@gmail.com>
Sent: Monday, March 7, 2022 7:29 PM
To: Log4J Users List <lo...@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 <Po...@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log level settings are not working correctly and getting wrong value
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hello Pooja,
On Mon, Mar 7, 2022 at 1:40 PM Pooja Pandey
<Po...@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Log level settings are not working correctly and getting wrong value
Posted by Pooja Pandey <Po...@asg.com.INVALID>.
-> 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();
if (!isGeneralLogger)
return configuredLevel;
Level currLevel = myLevel.get();
if (currLevel == null)
return configuredLevel;
if (configuredLevel == null)
return currLevel;
if (currLevel.isGreaterOrEqual(configuredLevel))
return configuredLevel;
return currLevel;
}
-----Original Message-----
From: Piotr P. Karwasz <pi...@gmail.com>
Sent: Monday, March 7, 2022 6:06 PM
To: Log4J Users List <lo...@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 11:23 AM Pooja Pandey <Po...@asg.com.invalid> wrote:
> I think there is something wrong with Log4j1.x bridge level handling when migrating from log4j1.x to log4j2.x.
>
> Issue: In my config file, log level is set to "Error", but with log4j1.x bridge log level is getting calculated as DEBUG. I think this is since in log4j1.x from FATAL to DEBUG level integer value decreases as shown below but in log4j2.x from FATAL to DEBUG integer value increases as shown below.
The order of Log4j 2.x numerical levels is the inverse of the Log4j 1.x order. However, that should have no influence on the result of `org.apache.log4j.Category#getEffectiveLevel()`, if that is the function you are referring to.
If I recall correctly, you are using a custom `Logger` class. My guess is that you overrode the `getEffectiveLevel()` with some custom logic.
Be aware that in the Log4j 1.x bridge the field `Category#level` is almost always `null`, while `Category#getLevel()` is an alias for `Category#getEffectiveLevel()` (never `null`).
If that is not the case, can you run your application with `-Dlog4j2.debug=true` and send you configuration file and the output of the status logger (it's printed to the application's standard error)?
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log level settings are not working correctly and getting wrong value
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hello Pooja,
On Mon, Mar 7, 2022 at 11:23 AM Pooja Pandey
<Po...@asg.com.invalid> wrote:
> I think there is something wrong with Log4j1.x bridge level handling when migrating from log4j1.x to log4j2.x.
>
> Issue: In my config file, log level is set to "Error", but with log4j1.x bridge log level is getting calculated as DEBUG. I think this is since in log4j1.x from FATAL to DEBUG level integer value decreases as shown below but in log4j2.x from FATAL to DEBUG integer value increases as shown below.
The order of Log4j 2.x numerical levels is the inverse of the Log4j
1.x order. However, that should have no influence on the result of
`org.apache.log4j.Category#getEffectiveLevel()`, if that is the
function you are referring to.
If I recall correctly, you are using a custom `Logger` class. My guess
is that you overrode the `getEffectiveLevel()` with some custom logic.
Be aware that in the Log4j 1.x bridge the field `Category#level` is
almost always `null`, while `Category#getLevel()` is an alias for
`Category#getEffectiveLevel()` (never `null`).
If that is not the case, can you run your application with
`-Dlog4j2.debug=true` and send you configuration file and the output
of the status logger (it's printed to the application's standard
error)?
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org