[logback-user] Sifting Appender works great

[Martin Burchard]

I used this configuration for testing...

<configuration>
	<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender">
		<discriminator>
			<Key>process</Key>
			<DefaultValue>unknown</DefaultValue>
		</discriminator>
		<sift>
			<appender name="DocApp-${process}"
class="de.pentos.domino.logging.DocumentAppender">
				<DBPath>${process}</DBPath>
				<layout class="ch.qos.logback.classic.PatternLayout">
					<Pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</Pattern>
				</layout>
			</appender>
		</sift>
	</appender>
	<root level="DEBUG">
		<appender-ref ref="SIFT" />
	</root>
</configuration>

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.");
		super.stop();
	}

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 =
lc.getLogger(LoggerContext.ROOT_NAME);
		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.