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@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