[logback-dev] [JIRA] Commented: (LBCLASSIC-178) Logger.callAppenders() doesn´t call TurboFilters

[David Sanz (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11494#action_11494 ] 

David Sanz commented on LBCLASSIC-178:
--------------------------------------

Hi Ceki,

Regarding point 3: Yes you are right:  TurboFilters are called.

About the solution you propose, I can confirm: It works. I am already using it.


Please consider updating the example in the manual
Chapter 4 : JMSTopicAppender with the new line
 logger.isDebugEnabled() 


Thanks again, 




> Logger.callAppenders() doesn´t call TurboFilters
> ------------------------------------------------
>
>                 Key: LBCLASSIC-178
>                 URL: http://jira.qos.ch/browse/LBCLASSIC-178
>             Project: logback-classic
>          Issue Type: Bug
>    Affects Versions: 0.9.18
>         Environment: Platform independent
>            Reporter: David Sanz
>            Assignee: Ceki Gulcu
>
> Using JMSQueueAppender for remote logging, and Logger.callAppenders() in the server sid,e never reload de logback configuration files.
> I am developing a client application, let´s say App1.
> App1 use the logback JMSQueueAppender, to deliver logging events to a Message Driven Bean, in the server side.
> As proposed in the logback manual my Message Driven Bean implements the following lines (simplified to make the explanation easier to understand)
> public void onMessage(javax.jms.Message message) {
>   ILoggingEvent event;
>  ...
>   ObjectMessage objectMessage = (ObjectMessage) message;
>  event = (ILoggingEvent) objectMessage.getObject();
>  Logger log = (Logger) LoggerFactory.getLogger(event.getLoggerName());
>  log.callAppenders(event);
> This is the only way i use Logger in the server side. I never use calls like log.debug(...) or similars
> In the server-side (MDB) I have set up a configuration with these line:
> <configuration scan="true" scanPeriod="30 seconds" > 
> File automatically reload every 30 seconds.
> The problem is that it never reloads the configuration file.
> The cause is the following.
> In the logback site we can read, about the scan attribute in the configuration file:
> "
> Behind the scenes, when you set the scan attribute to true, a TurboFilter called ReconfigureOnChangeFilter  will be installed. TurboFilters are described in a later chapter. As a consequence, scanning is done "in-thread", that is anytime a printing method of logger is invoked. 
> "
> And the fact is that Logger.callAppenders() doesn´t  check the turbofilters, and thus it never reloads the configuration file.
> Proposed solution:  (may be is not de correct one, but i think it could solve the problem):
> Modify  callAppenders(ILoggingEvent event) 
> Add the following  line at the beggining of the method:
> boolean enabled = isEnabledFor(event.getLevel());  //call indirectly turbofilters
> and besides we could use enabled to return directly (if  not enabled)
> if (!enabled) {
> return 
> }
> So the new code could be something like 
>   /**
>    * Invoke all the appenders of this logger.
>    * 
>    * @param event
>    *                The event to log
>    */
>   public void callAppenders(ILoggingEvent event) {
>     boolean enabled = isEnabledFor(event.getLevel()); 
>     if (!enabled) {
>      return  ;
>      }
>     int writes = 0;
>     for (Logger l = this; l != null; l = l.parent) {
>       writes += l.appendLoopOnAppenders(event);
>       if (!l.additive) {
>         break;
>       }
>     }
>     // No appenders in hierarchy
>     if (writes == 0) {
>       loggerContext.noAppenderDefinedWarning(this);
>     }
>   }
> Thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira