- logback-user - mailman3.qos.ch

Re: [logback-user] RE: [logback-user] logback initialization "à la" Spring
by Arthur Blake 27 Sep '07

27 Sep '07

I would probably be a little more inclined to open source it on my own, as I'm not too fond of the LGPL. Would it be considered LGPL anyway if it's dependent on logback? I don't think it would... I would much prefer MIT or Apache. I would prefer to make it work against SLF4J as that would allow it to be used in a lot more situations, but SLF4J has no concept or API for querying existing loggers/appenders, etc. (and I understand why-- it would be pretty hard to generalize all that) sorry for the thread drift... ----- Original Message ---- From: Ceki Gulcu <listid(a)qos.ch> To: logback users list <logback-user(a)qos.ch> Sent: Thursday, September 27, 2007 4:33:21 PM Subject: Re: [logback-user] RE: [logback-user] logback initialization "à la" Spring I encourage you to create your own project. Alternatively, you could contribute your code to the logback. Assuming the following conditions: 0) you intend to maintain it 1) you don't mind other logback developers rummaging through and refactoring your code :-) 2) you agree to the terms of the "Contributor License Agreement" [1] As for jabsorb.org, I've added it to the list. [1] http://logback.qos.ch/cla.txt Arthur Blake wrote: > 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 > -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user(a)qos.ch http://qos.ch/mailman/listinfo/logback-user ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/

1 0

Re: [logback-user] RE: [logback-user] logback initialization "à la" Spring
by Arthur Blake 27 Sep '07

27 Sep '07

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 <ceki(a)qos.ch> To: logback users list <logback-user(a)qos.ch> 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 <blakesys(a)yahoo.com> > To: logback users list <logback-user(a)qos.ch> > 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 <tleccese(a)cybershift.com> > To: logback users list <logback-user(a)qos.ch> > 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:* logback-user-bounces(a)qos.ch > [mailto:logback-user-bounces@qos.ch]*On 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 <jorg.heymans(a)gmail.com> > To: logback users list <logback-user(a)qos.ch> > Sent: Thursday, September 27, 2007 10:23:07 AM > Subject: Re: [logback-user] logback initialization "à la" Spring > > On 9/27/07, *Davide Baroncelli* <baroncelli(a)yahoo.com > <mailto:baroncelli@yahoo.com>> 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.co…> > 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_pa…> > 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=X3oDMTFi…> > with Yahoo! FareChase. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Logback-user mailing list > Logback-user(a)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 _______________________________________________ Logback-user mailing list Logback-user(a)qos.ch 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

2 1

Re: [logback-user] RE: [logback-user] logback initialization "à la" Spring
by Arthur Blake 27 Sep '07

27 Sep '07

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 <blakesys(a)yahoo.com> To: logback users list <logback-user(a)qos.ch> 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 <tleccese(a)cybershift.com> To: logback users list <logback-user(a)qos.ch> Sent: Thursday, September 27, 2007 12:57:36 PM Subject: [logback-user] RE: [logback-user] logback initialization "à la" Spring DIV { MARGIN:0px;} 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: logback-user-bounces(a)qos.ch [mailto:logback-user-bounces@qos.ch]On 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 <jorg.heymans(a)gmail.com> To: logback users list <logback-user(a)qos.ch> Sent: Thursday, September 27, 2007 10:23:07 AM Subject: Re: [logback-user] logback initialization "à la" Spring On 9/27/07, Davide Baroncelli <baroncelli(a)yahoo.com> 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 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 and lay it on us. ____________________________________________________________________________________ Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658

2 1

Interest in JDK 1.4 builds?
by Ceki Gulcu 27 Sep '07

27 Sep '07

Hello all, Logback includes retro-weaver generated jars for JDK 1.4. However, there seems to be little interest in these JDK 1.4 jars. Calling retro-weaver increases logback's build time by a few seconds -- seconds in which we can do more productive things. So, is there any interest in the JDK 1.4 build of logback? If not, I intend to remove JDK 1.4 support in logback for the next release. Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

6 7

Re: [logback-user] RE: [logback-user] logback initialization "à la" Spring
by Arthur Blake 27 Sep '07

27 Sep '07

Not necessarily, the reload check could be done before the OFF check... ----- Original Message ---- From: Tom Leccese <tleccese(a)cybershift.com> To: logback users list <logback-user(a)qos.ch> Sent: Thursday, September 27, 2007 12:57:36 PM Subject: [logback-user] RE: [logback-user] logback initialization "à la" Spring DIV { MARGIN:0px;} 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: logback-user-bounces(a)qos.ch [mailto:logback-user-bounces@qos.ch]On 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 <jorg.heymans(a)gmail.com> To: logback users list <logback-user(a)qos.ch> Sent: Thursday, September 27, 2007 10:23:07 AM Subject: Re: [logback-user] logback initialization "à la" Spring On 9/27/07, Davide Baroncelli <baroncelli(a)yahoo.com> 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 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. ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting

1 0

Re: [logback-user] logback initialization "à la" Spring
by Arthur Blake 27 Sep '07

27 Sep '07

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 <jorg.heymans(a)gmail.com> To: logback users list <logback-user(a)qos.ch> Sent: Thursday, September 27, 2007 10:23:07 AM Subject: Re: [logback-user] logback initialization "à la" Spring On 9/27/07, Davide Baroncelli <baroncelli(a)yahoo.com> 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 ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

2 1

Simple question about appender SOCKET on logback
by Vicente Ferrer 25 Sep '07

25 Sep '07

Hi to all, I have a simple question about logback. Is the SOCKET appender compatible with old log4j SOCKET appender? Is posible to use Chainsaw or Ganymede eclipse plugin, for example, with an enviroment based on logback and a SOCKET appender configured on it? Thanks, Vte. Ferrer

2 1

simple question driving me crazy..
by Alex Hoyos 20 Sep '07

20 Sep '07

I need to have different ROOT logger levels (INFO,DEBUG,WARN,etc) to different appenders (file..) something like: <configuration> <!-- ..... appender defintitions ---- > <root> <level value="debug" /> <appender-ref ref="STDOUT" /> </root> <another root???> <level value="error" /> <appender-ref ref="errorLog" /> </root> </configuration> But I'm not sure how to do this syntax in the XML config file. Looked through the documentation and examples, and I did not see it. Any one can help, I appreciate it... -- Regards, Alex Hoyos

3 3

Unable to use SLF4j's MDC with logback 0.9.7.
by Pascal Jacob 16 Sep '07

16 Sep '07

Hello dear logback commiters, I'm trying to use SLF4j MDC in my multithread program and i'm having the following error: SLF4J: Failed to load class "org.slf4j.impl.StaticMDCBinder". SLF4J: See http://www.slf4j.org/codes.html#no_static_mdc_binder for further details. Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/impl/StaticMDCBinder at org.slf4j.MDC.<clinit>(MDC.java:70) at fr.mipih.jms.AsynchConsumer.<init>(AsynchConsumer.java:50) at fr.mipih.jms.AsynchConsumer.main(AsynchConsumer.java:182) I have the following jars in the classpath : slf4j-api-1.4.2.jar jcl104-over-slf4j-1.4.2.jar logback-classic-0.9.7.jar logback-core-0.9.7.jar I have check the content of the jars and in fact StaticMDCBinder is nowhere to be found (should be in logback-classic-0.9.7.jar as I understand it) I have checked the repository at http://svn.qos.ch/repos/logback/trunk and found that StaticMDCBinder was added in logback-classic\src\main\java\org\slf4j\impl back somewhere in may. I have no [easy] way to compile the new source code on my platform since logback use maven (don't have it, don't want to install it, don't want to learn how to use it). Isn't it time to release a 0.9.8 or something (why not a 1.0) so that slf4j's MDC (and other bug fixes) are available to the majority ? TIA. ZC.

4 3

Unexpected problem with logback
by Vicente Ferrer 14 Sep '07

14 Sep '07

Hi, I´m an habitual user of log4j and I´m trying to port my application to logback. The first impression of this new tool was very good; the pluggin for Eclipse IDE has a good apparience. But I´m experiencing a little worrisomely problem: some logging lines cause the Eclipse plugin stops to write the rest of logging lines. If I activate a ConsoleAppender, I can view the rest of the logging lines at the standard console, but the Eclipse plugins don´t show that lines. The line causing the Eclipse plugin stops to work is: Method[] methods = clazz.getDeclaredMethods(); log.debug("method: {}", methods[i]); I´ve seen an error on the Error Log eclipse´s view saying that java.lang.reflect.Method is not Serializable, and the plugin do not show the rest of the logging lines. I´ve experimented similar error when I try to log a message line that contains an own object such as a bean. In this case, the error is a ClassNotFoundError because of the logback eclipse plugin can´t find the bean class. Do you think these are two bugs of the plugin? How do you think I can solve that problems?

1 0