[logback-user] Sifting Appender works great

Martin Burchard martin.burchard at pentos.com
Sun Mar 8 16:57:10 CET 2009

I used this configuration for testing...

	<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender">
			<appender name="DocApp-${process}"
				<layout class="ch.qos.logback.classic.PatternLayout">
					<Pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</Pattern>
	<root level="DEBUG">
		<appender-ref ref="SIFT" />

There is only one thing to do... It's essential to close the Domino based
appenders (you know, the Domino object problems)
I implemented this method in the DocumentAppender.

	public void stop() {
		// TODO Auto-generated method stub
		System.out.println("I " + dbPath + " get stopped now.");

But I never see this sysout :(
How can I explicitly stop the Appender? I tried to get my Appender, but I
only can get the sifting appender.

		LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
		UUID uuid = UUID.randomUUID();
		MDC.put("process", uuid.toString());
		ch.qos.logback.classic.Logger root =
		Appender<LoggingEvent> sift = root.getAppender("SIFT");
		if (sift != null) {
			log.debug("gut the sifting Appender {}", sift.getName());
			SiftingAppender sifting = (SiftingAppender) sift;
		Appender<LoggingEvent> x = root.getAppender("DocApp-" + uuid.toString());
		if (x != null) {
			log.debug("got the Appender {}", x.getName());

Is this last thing possible?

Ceki Gulcu wrote:
> Martin Burchard wrote:
>  > Using this way, is it possible to have the Logger configuration also
>  > on a per Thread basis?
> No, SiftingAppender only controls the appenders nested within it. It
> does not control the configuration of loggers.
>> Reading through Chapter 9: Context Selectors I have seen the
>> ContextJNDISelector and now it sounds to me, that ContextSelector isn't
>> such
>> a good idea?
> Context selection is a possible approach but logback offers other
> alternative approaches, e.g. SiftingAppender. Given the unfamiliarity
> of your environment, it is not possible to propose the right approach
> off the bat.
> However, you have correctly identified one problem with context selectors,
> that 
> is static definition of logger variables. This is a known weakness of
> context 
> selectors. However, assuming that you are mostly interested in the logs 
> generated by your own code and less about code generated by the libraries
> you 
> use, you could force logger variables to be non-static and just ignore
> logs 
> generated by static logger variables.
> -- 
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user

View this message in context: http://www.nabble.com/ContextSelector-and-getLogger-tp22352655p22399443.html
Sent from the Logback User mailing list archive at Nabble.com.

More information about the Logback-user mailing list