executing configuration changes
Hello, I'm investigating slf4j + logback, if it solves my requirements: I need to change the logging configuration during application runtime and read the documentation about the config file scan. Can this reconfiguration be done by my self without using the scan? More precisely: can I add and remove an own TurboFilter during runtime from my program code? How about logging events fired while applying these changes? Is it guaranteed, that no event will be lost? Best regards, Lars
1. We wrote a servlet filter that inspects the configuration periodically and resets the configuration if the file has changed. When running as a web app this will incur less overhead than the turbo filter. 2. The architecture of Logback is such that when a reconfigure occurs all the filters and appenders are removed first so it is almost guaranteed that events will be lost during a reconfiguration. I've been working on Log4J 2.0 which was designed to not have this design defect. Ralph On Jan 19, 2011, at 12:53 AM, Lars Fischer wrote:
Hello,
I'm investigating slf4j + logback, if it solves my requirements:
I need to change the logging configuration during application runtime and read the documentation about the config file scan.
Can this reconfiguration be done by my self without using the scan? More precisely: can I add and remove an own TurboFilter during runtime from my program code? How about logging events fired while applying these changes? Is it guaranteed, that no event will be lost?
Best regards, Lars _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Hallo Ralph, thank you for the reply! 2011/1/19 Ralph Goers <rgoers@apache.org>:
1. We wrote a servlet filter that inspects the configuration periodically and resets the configuration if the file has changed. When running as a web app this will incur less overhead than the turbo filter.
Good to know, but I need to use different filters per user. I read about the TurboFilter feature and would give it a try even though it has a performance impact.
2. The architecture of Logback is such that when a reconfigure occurs all the filters and appenders are removed first so it is almost guaranteed that events will be lost during a reconfiguration. I've been working on Log4J 2.0 which was designed to not have this design defect.
Do I understand it right? It is guaranteed that events will be lost? Is there no way to prevent this? I do not need to reconfigure the whole logging context. Only one TurboFilter has to be added or removed. It's no problem for me, if some events will be not recognized by this TurboFilter during or short time after applying the changes. But existing loggers and appenders must process all events... Best regards, Lars
participants (2)
-
Lars Fischer -
Ralph Goers