Hi Daniel, Thanks for the info - glad there are others out there with similar requirements. I guess a separate logger specifically for this purpose is another way to approach it alright - definitely worth considering. I think I'm gonna try extending the existing ThresholdFilter (or creating a new filter based on it) as a first attempt, see how that goes, and failing that try the separate logger route. Good to have options.
Regards, Shane On 19 December 2012 00:12, Daniel Ferber <[email protected]> wrote: > Hi Shane, > > In a similar situation, I used another approach. First I considered using > markers on each initialization log message. Then I used a logger dedicated > exclusively for initialization. This dedicated logger was configured to log > everything, regardless of other loggers. > > Both solutions, markers or dedicated logger, require you to handle the > initialization messages differently and to provide proper configuration for > them. IMHO, the approach of a dedicated logger is much simpler to > understand and to configure. > > Best regards, > Daniel Felix Ferber > > 2012/12/14 Shane Kelly <[email protected]> > >> Folks, >> >> Just wondering if there is a capability within Logback for writing a log >> message regardless of whatever log level has been set in configuration. >> Consider the scenario where I want my web application to output some >> diagnostic information at startup or shutdown - for example, the Web >> Application version, build date etc. If I were to set the log level of >> these messages to be TRACE, DEBUG, or INFO then its possible they may never >> be displayed since the app may typically be configured to run with a log >> level of WARN. Similarly, I don't want to set the log level of the messages >> to WARN, ERROR or FATAL in order to ensure that they do get displayed since >> they're not really error messages, and if we monitor the log files for >> WARN, ERROR or FATAL messages then this would trigger a false positive. >> >> So, is there some way to force a message to be logged at all times, >> independently of log level? Or some way to achieve this effect via existing >> configuration. Arguably I suppose this is bending the rules slightly, in >> that it could be abused - why offer the ability to filter certain log >> levels if an application can override/ignore them - but perhaps this is >> something which could be configurable/switchable? >> >> Regards, >> >> Shane >> >> _______________________________________________ >> Logback-user mailing list >> [email protected] >> http://mailman.qos.ch/mailman/listinfo/logback-user >> > > > _______________________________________________ > Logback-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/logback-user >
_______________________________________________ Logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
