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

Ceki Gulcu (JIRA) noreply-jira at qos.ch
Sun Jan 3 21:31:33 CET 2010

     [ http://jira.qos.ch/browse/LBCLASSIC-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ceki Gulcu resolved LBCLASSIC-178.

    Resolution: Won't Fix

As Ralph mentioned, the suggested modification does not make sense because by construction when the callAppenders method is invoked, the logger is enabled for the requested level. I am not very keen on adding a new method to the Logger class. Moreover, invoking logger.isDebugEnabled() method in your MDB will achieve the effect you are looking for, that is the invocation of TurboFilters.

Consequently, I am marking this issue as won't fix.

> 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


More information about the logback-dev mailing list