[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