[
https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515066#comment-17515066
]
Pooja Pandey commented on LOG4J2-3455:
--------------------------------------
Hi [~rgoers],
Thank you for your response!
Below is what defines our requirement.
"
Our application has a standard for command line clients – that they should
accept a command line parameter that overrides the logging threshold for
operations in aid of that client on both the client and server sides. The
server is operating on behalf of any number of clients simultaneously and in
normal operation is sparing in what it actually writes to the log file.
We are using CustomLogger class which is a specialization of the log4j Logger
class. log4j uses an approach of fine grained log level control, driving its
specialization by the name of the logger used. Named loggers may have different
thresholds, usually configured through specific entries in the properties file.
If we want to provide operation level threshold control, it cannot be done
using any of log4j’s natural approaches to the problem.
To achieve the command line client specific log level threshold, we capture the
threshold setting as a thread local variable. The value of the variable is used
in an override of the getEffectiveLevel method from log4j’s Logger class.
log4j1.x uses getEffectiveLevel internally to determine the threshold for
logging messages. The net effect of this approach is that a body of code can
set the threshold at a higher logical level of the code and all lower level
code invoked by that level will respect the lower threshold without needing be
otherwise told. On exit from the high level function, it must clear the
threshold setting so that other operations that reuse the thread do not
encounter a spurious setting.
However since now we have migrated to log4j1.x 2.17.2 bridge and it doesn't use
getEffectiveLevel() internally, which has broken our feature and to fix the
feature we have implemented a workaround where we set/clear threshold with
Log4j2 API directly.
"
> Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
> --------------------------------------------------------------------------
>
> Key: LOG4J2-3455
> URL: https://issues.apache.org/jira/browse/LOG4J2-3455
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.17.2
> Reporter: Pooja Pandey
> Priority: Major
> Attachments: CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java,
> customlog.properties
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold
> doesn't work which used to work earlier with log4j1.x. We had achieved this
> feature by overriding getEffectiveLevel(), but now this doesn't work anymore
> with log4j1.x bridge since the method getEffectiveLevel() is not getting
> invoked to set effective level.
>
> For reference, Java class files for Custom Logger, Custom Multiprocess
> Rolling Appender and Test program are attached along with cutom log4j
> properties
> file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
