[logback-user] Sifting Appender works great

[Ceki Gulcu]

Hello Martin,

SiftingAppender tracks the appenders it creates in a data structure
called "AppenderTracer". See [1, 2, 3]. Only through this structure
can you access the appenders nested within a SiftingAppender.

Note that that unused or "stale" appenders will be closed by the
appender tracker after 30 minutes of non-use. Would closing your
DocumentAppender instances after 30 minutes work for you?

[1] http://logback.qos.ch/xref/ch/qos/logback/classic/sift/SiftingAppender.html
[2] http://logback.qos.ch/xref/ch/qos/logback/core/sift/AppenderTracker.html
[3] http://logback.qos.ch/xref/ch/qos/logback/core/sift/SiftingAppenderBase.html




Martin Burchard wrote:
> 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
>>
>>
> 

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch