It sounds to me like what you want is to use the SiftingAppender using a SystemPropertyDiscriminator.
Ralph On Sep 7, 2012, at 1:56 AM, Thorbjørn Ravn Andersen wrote: > Hi Ceki. > > Thank you for your prompt reply and a very interesting suggestion. > > It sounds to me that what you suggest - which essentially tells logback to > delay processing completely - require that our application will have to > leave the "use only SLF4J" paradigm that we have been very satisfied with, > and instead know the most intimates of intimate about not only logback but > also our logging configuration (which is by definition here unknown to the > programmer as it is the responsibility of the deployer - also we usually use > the Simple implementation while developing thanks to the flexibility of > Maven). I am not sure I like going there. > > Perhaps this is a bit overkill for our current needs? A slightly smarter > FileAppender might be better for us, perhaps? > > I'll ponder some more, and have a look at the code - perhaps a devious > workaround shows - has happended before :) > > Thanks > > /Thorbjørn > > > -----Original Message----- > From: logback-user-boun...@qos.ch [mailto:logback-user-boun...@qos.ch] On > Behalf Of ceki > Sent: 5. september 2012 15:34 > To: logback users list > Subject: Re: [logback-user] Handling log events happening before > configuration is ready? > > > > On 05.09.2012 14:29, Thorbjørn Ravn Andersen wrote: >> Very rapidly - usually within the first second. We are still in the >> initialization phase of our application. > > In that case, you could declare a buffer in logback.xml, buffer the events > until all the initialization information is available, and then configure > logback via another configuration file by invoking Joran directly as > explained at > > http://logback.qos.ch/manual/configuration.html#joranDirectly > > Once logback is configured a second time (and for good), you can replay the > events contained in the buffer. > > The initial Logback.xml could be as small as: > > <configure> > <appender name="LIST" class="ch.qos.logback.core.read.ListAppender"/> > <root level="DEBUG"> > <appender-ref ref="LIST"/> > </root> > </configure> > > > To obtain the appender named LIST: > > import ch.qos.logback.classic.Logger; > LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); > Logger root = lc.getLogger(Logger.ROOT_NAME); > ListAppender listAppender = (ListAppender ) root.getAppender("LIST"); > List<ILoggingEvent> eList = (List<ILoggingEvent>) listAppender.list; > > > Unfortunately, logback-classic does not offer an API for replaying events. > If however, you *know* that you have appenders A and B configured, you could > write: > > Appender appenderA = root.getAppender("A") > Appender appenderB = root.getAppender("B") > > for(ILogdingEvent event: eList) { > appenderA.doAppend(event); > appenderB.doAppend(event); > } > > > The main problem with this approach is that it requires the names of the > appenders in your second logback config file to be hardcoded. > However, there are ways to get around this limitation. > > -- > Ceki > http://tinyurl.com/proLogback > >> >> -----Original Message----- >> From: logback-user-boun...@qos.ch [mailto:logback-user-boun...@qos.ch] >> On Behalf Of ceki >> Sent: 4. september 2012 14:50 >> To: logback users list >> Subject: Re: [logback-user] Handling log events happening before >> configuration is ready? >> >> How much time are we talking about between logback initialization and >> the time where the value of the property is known? >> >> On 04.09.2012 14:38, Thorbjørn Ravn Andersen wrote: >>> We have done plain old “just log to a new file for the duration of >>> the program – delete old logs daily” for several years now and found >>> it works well for us. >>> >>> Now I have a rather tricky situation where part of the file name to >>> be used by (a subclass of) FileAppender needs to be supplied by my >>> code, but the initialization phase of the application contains log >>> statements triggering the initialization of logback _/before/_ the >>> property referred to by the FileAppender name string is set causing >>> the log file to have an incorrect name. >>> >>> Basically what I have found to be the behavior I want is for logback >>> to await opening the file and write data before I say it can. >>> >>> Question is how I can do this within the limits of logback. Can I >>> tell logback to just buffer events in memory (this will only be for a >>> few seconds, and memory will most likely not be an issue) – some kind >>> of valve? Can I tell FileAppender to write to a temporary file and >>> rename it whenever the name is ready (perhaps using some of the >>> Policies from RollingFileAppender)? >>> >>> Any suggestions on how to handle this? >>> >>> Note: As we restart our application daily we do not need >>> RollingFileAppender for our general logging – instead we have >>> subclassed FileAppender to remove “older than X days” files from the >>> target folder. This has proven to work very well for our scenario. >>> >>> Thanks >>> >>> /Thorbjørn >>> > > _______________________________________________ > Logback-user mailing list > Logback-user@qos.ch > http://mailman.qos.ch/mailman/listinfo/logback-user > > _______________________________________________ > Logback-user mailing list > Logback-user@qos.ch > http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
