qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6620) [Java Broker] Restore the behaviour of the if(LOGGER.isDebugEnabled()) idiom (but restrict its use)
Date Mon, 13 Jul 2015 11:35:04 GMT

    [ https://issues.apache.org/jira/browse/QPID-6620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624547#comment-14624547

Keith Wall commented on QPID-6620:

I'm puzzled by the need for all the static methods.  Surely there is a simpler way?  If QpidLoggerTurboFilter
was created and installed on the LoggerContext  (say in org.apache.qpid.server.Broker#startup(org.apache.qpid.server.BrokerOptions))
and QpidLoggerTurboFilter was changed to listen to the model so it could hear the addition/removal
of *LoggerFilter, it would have all the information needed for its work?

The change to remove the memory logger from test config  so that the turbo filter would no
longer find its filter and reduce the logger level to INDFO during test runs is made.

> [Java Broker] Restore the behaviour of the if(LOGGER.isDebugEnabled()) idiom (but restrict
its use)
> ---------------------------------------------------------------------------------------------------
>                 Key: QPID-6620
>                 URL: https://issues.apache.org/jira/browse/QPID-6620
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>    Affects Versions: 6.0 [Java]
>            Reporter: Rob Godfrey
>            Assignee: Rob Godfrey
>             Fix For: 6.0 [Java]
> Recent changes to the logging mechanism in the broker mean that us of the idiom
> {code}
> if(_logger.isDebugEnabled())
> {
>     _logger.debug(...)'
> }
> {code}
> no longer prevents the debug statement being evaluated when debug logging is not switched
> In order to restore this behaviour we need to add a "TurboFilter" which can evaluate
whether the logger will actually log the statement.
> Additionally we should reduce the use of this idiom and instead use the ability of logback/slf4j
to use patterns with parameters rather than dynamically building up the logged string.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message