A minor correction to my earlier response - I defined the <turboFilter> in the <configuration> section, and *not* within the <appender>
Regards, Shane On 18 December 2012 23:46, Shane Kelly <logb...@ballinascreen.com> wrote: > Ceki, Ralph, > > I did try the TurboFilter as suggested, however, something which I > probably didn't make explicitly clear in my original post was that I > configure a ThresholdFilter within each of my appenders to filter out > messages below a certain level - as I said previously, its likely that the > application I'm working on will be configured only to log messages of WARN > and above. For example: > > <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> > > <turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter"> > <Name>ALWAYSLOG</Name> > <Marker>ALWAYSLOG</Marker> > <OnMatch>ACCEPT</OnMatch> > </turboFilter> > > <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> > <level>WARN</level> > </filter> > > ... > ... > > </appender> > > Although the Marker turbofilter is ACCEPTing messages which contain the > appropriate 'marker' as expected, the message will then get filtered out by > the subsequent the Threshold filter - I suppose I could extend the standard > Threshold filter to look for the presence of the marker and bypass normal > threshold filtering in these cases... or did I misunderstand something? > > Regards, > > Shane > > On 18 December 2012 14:46, ceki <c...@qos.ch> wrote: > >> Shane, >> >> Were you able to make progress on this issue? >> >> >> On 15.12.2012 01:56, Shane Kelly wrote: >> >>> Ralph, >>> >>> Thanks for your suggestion - after a quick skim through the >>> documentation it certainly looks like markers may provide the behaviour >>> I'm looking for - will give that a try. >>> >>> Regards, >>> >>> Shane >>> >>> >>> On 15 December 2012 00:21, Ralph Goers <rgo...@apache.org >>> <mailto:rgo...@apache.org>> wrote: >>> >>> Use a Marker. Then set a Marker filter to always accept events with >>> that Marker. >>> >>> Ralph >>> >>> >>> On Dec 14, 2012, at 2:42 PM, Shane Kelly wrote: >>> >>> > 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 >>> >>> >> >> -- >> Ceki >> http://twitter.com/#!/ceki >> >> ______________________________**_________________ >> Logback-user mailing list >> Logback-user@qos.ch >> http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user> >> > >
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
