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

Rob Godfrey commented on QPID-6620:
-----------------------------------

So - originally I added the turbo logger on construction of a filter by looking 
up the broker ancestor and then getting the turbo logger from that - however 
this caused lots of unit test failures as we use mock brokers which then didn't 
have a turbo filter on them.  I then changed to doing if - null checks which 
was solely to support the unit test cases (which I *really* dislike doing).  
Given a choice I think this would still be my preferred mechanism, however 
since the code in AbstractLogger is in reality already depending on the static 
root context it didn't seem like it was making things any worse by adding 
static methods to the QpidLoggerturboFilter.

In general I dislike using listeners for this sort of thing too - you introduce 
timing / ordering questions that seem too high a price to pay.

> [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 on.
> 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
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to