Ceki said: >Perhaps the cleanest solution is to trigger reloading of the config file >manually via some convenient (graphical?) user interface.
I wrote a really nice ajax based graphical UI for log4j recently for a client that does all that. It worked out so well, I've been toying of the idea of making an open source one for logback. I prefer logback for my own open source projects. If there is significant interest in this I might consider doing this and either contributing to logback or open sourcing it on my own... PS. Ceki, I have yet another open source library that is now dependent on SLF4J (see http://jabsorb.org) - nice if you could add that to the main SLF4J page. Cheers ----- Original Message ---- From: Ceki Gulcu <[EMAIL PROTECTED]> To: logback users list <[email protected]> Sent: Thursday, September 27, 2007 2:31:37 PM Subject: Re: [logback-user] RE: [logback-user] logback initialization "à la" Spring Hello, Because it dispenses with the need of a separate watchdog thread, I believe that the approach discussed here has significant merit. It could be placed into a custom TurboFilter. TurboFilters get called very early in the processing of a log statement. In other words, they get called every time, regardless of the level of the logger in question. The if(now > nextCheckStamp) check should avoid superfluous access to the configuration file. Of course, the value of "now" would need to be computed anew for each log statement. Preliminary tests show that a call to System.currentTimeMillis() costs about 70 nanoseconds. Admittedly, 70 nanoseconds is not much but when compared to the cost of a disabled log statement (10 nanoseconds), it becomes an non-negligible issue. In short, the approach is promising, with a small but non-negligible computational cost. Perhaps the cleanest solution is to trigger reloading of the config file manually via some convenient (graphical?) user interface. Arthur Blake wrote: > Probably one objection to this scheme would be an extra overhead on each > and every log message-- if you really look into it though, this overhead > is really really minor- > I think if implemented correctly, it would amount to just an extra long > comparison on each log message. > e.g. > > if (now > nextCheckTstamp) > { > // kick off async file check > // and then update nextCheckTstamp > } > > Where "now" is a variable that you presumably would already have around > anyway... > > > ----- Original Message ---- > From: Arthur Blake <[EMAIL PROTECTED]> > To: logback users list <[email protected]> > Sent: Thursday, September 27, 2007 1:11:04 PM > Subject: Re: [logback-user] RE: [logback-user] logback initialization "à > la" Spring > > Not necessarily, the reload check could be done before the OFF check... > > ----- Original Message ---- > From: Tom Leccese <[EMAIL PROTECTED]> > To: logback users list <[email protected]> > Sent: Thursday, September 27, 2007 12:57:36 PM > Subject: [logback-user] RE: [logback-user] logback initialization "à la" > Spring > > One snafu, perhaps. If all your loggers in your current config are > turned OFF, then a message would never get generated, and it would never > check to see if the config file has changed. > > -----Original Message----- > *From:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of *Arthur Blake > *Sent:* Thursday, September 27, 2007 12:45 PM > *To:* logback users list > *Subject:* Re: [logback-user] logback initialization "à la" Spring > > I've used automatic reloading in the past in log4j and it certainly > can be a very nice and convenient feature-- > > There are various issues that come up in the complexity of > implementing it -- normally it's done with a separate Thread that > runs and wakes up every so often to check if the file timestamp on > the config file has changed. > > Thats a bit of a clunky and complex way to do it. > > I have been mentally toying with an idea for a new way to accomplish > this, without having to have a separate thread-- The check could be > done at the point where each log message is generated-- system wide. > > Since you already know the timestamp of the message generated, you > could just compare that to the timestamp of the last time the log > config file was reloaded-- and if a certain amount of time has > elapsed since the last time the file was checked, you kick off the > code that checks to see if the file time stamp has changed, and if > so, reload it (that part could be done asynchronously as well so as > not to slow down other threads writing out log messages) > > It's simple, fast and it would have the very nice benefit of not > having to have a separate Thread-- furthermore, you avoid the > overhead of periodically checking the modification file stamp, over > long periods when there is no log activity (such as idle periods > when a server might not be getting any activity) > > Has anyone thought of implementing it this way? > > > ----- Original Message ---- > From: Jorg Heymans <[EMAIL PROTECTED]> > To: logback users list <[email protected]> > Sent: Thursday, September 27, 2007 10:23:07 AM > Subject: Re: [logback-user] logback initialization "à la" Spring > > On 9/27/07, *Davide Baroncelli* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > P.s.: let me express my disagreement for logback and sl4j not > supporting > neither the FATAL logging level nor automatic reloading of > config files. > > > +1 for automatic reloading ! > > Jorg > > > ------------------------------------------------------------------------ > Catch up on fall's hot new shows > > <http://us.rd.yahoo.com/tv/mail/tagline/falltv/evt=47093/*http://tv.yahoo.com/collections/3658%20> > on Yahoo! TV. Watch previews, get listings, and more! > > > This e-mail and any attachments may contain confidential and privileged > information. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this e-mail and destroy any > copies. Any dissemination or use of this information by a person other > than the intended recipient is unauthorized and may be illegal. > > > ------------------------------------------------------------------------ > Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user > panel > <http://us.rd.yahoo.com/evt=48516/*http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7%20> > > and lay it on us. > > > ------------------------------------------------------------------------ > Looking for a deal? Find great prices on flights and hotels > <http://us.rd.yahoo.com/evt=47094/*http://farechase.yahoo.com/;_ylc=X3oDMTFicDJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20-> > > with Yahoo! FareChase. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Logback-user mailing list > [email protected] > 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 _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
_______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
