[ http://jira.qos.ch/browse/LBCLASSIC-178?page=com.atlassian.jira.plugin.syste... ] David Sanz commented on LBCLASSIC-178: -------------------------------------- Hi Ralph, Thank you for your response. I am sorry for making such a horrible proposal. I supposed that the modification I proposed, wouldn´t be the good one. But at least it have let me to explain the problem. I don´t know logback´s code in deep. But the reasons argued by you are quite rational. The solution you prosose fits also my needs, whenever the new method: log(ILoggingEvent) calls the turbofilters and thus checks ReconfigureOnChangeFilter After modifying it would be necessary to update also logback´s manual to make reference to the new method instead of callAppender in: Chapter 4 : JMSTopicAppender 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

[ http://jira.qos.ch/browse/LBCLASSIC-178?page=com.atlassian.jira.plugin.syste... ] 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

[ http://jira.qos.ch/browse/LBCLASSIC-178?page=com.atlassian.jira.plugin.syste... ] 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