[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=11492#action_11492 ] 

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

Hi Cecki,

1º Thank you very much for your efforts.
2º The temporal solution I adopted before commiting this issue was similiar to the one you have proposed. Calling isEnabledFor(Level level) before callAppenders method
3 º Even using this trick, NONE of the turboFilters will be applied on the MDB side. ReconfigureOnChangeFilter is just one of them
4º I understand that you don´t want to modify Logger interface (which by the moment its quite clean, congratulations for that)
5º I dissappoint in marking it as won´t fix. May be it is not a blocking bug. But as far as I see, forcing a MDB developper to add an additonal call to logger.isDebugEnabled() just for reload configuration its not a clearest way and not obvious
6º I have thought that making public method Logger.callTurboFilters(...) could be also a solution. But the price it´s the same: modifing the public interface of Logger class.

8º The perfect solution should not force developper to make additional calls, and make this reloading configuration stuff transparently. I think you would agree with me.

I will not disturbe you again with this issue. Once I have explained the problem, and as you have understood, I leave you make you decision.

In case of you lastly decide not fixing it...
I think other developpers would appreciate updating the example in the manual
Chapter 4 : JMSTopicAppender with the new line
 logger.isDebugEnabled()

Thank you very much, and congratulations for this great product. 

> 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