[
http://jira.qos.ch/browse/LBCLASSIC-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11489#action_11489
]
Ralph Goers commented on LBCLASSIC-178:
---------------------------------------
I am very opposed to this. TurboFilters are called before the LoggingEvent is
constructed which measurably improves performance when logging is disabled. In
addition, if the event doesn't pass the TurboFilters then the event doesn't
even make it to the Loggers and the callAppenders method.
Moving them to callAppenders is a horrible idea because they would now be
invoked once before the LoggingEvent is constructed (this has to remain or the
TurboFilters will no longer be global) and again in each Logger that has
appenders configured (which is a complete waste since they already passed).
A much better solution would be to enhance Logback's Logger class to add
log(ILoggingEvent) which your MDB could then call.
> 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: Logback dev list
>
> 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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
