- logback-dev - mailman3.qos.ch

[JIRA] Commented: (LBCLASSIC-46) ThrowableInformation should keep the Throwable cause hierarchy intact.
by Joern Huxhorn (JIRA) 17 Nov '08

17 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn commented on LBCLASSIC-46: ---------------------------------------- Well, you are right about the reconstruction. It's still possible, even though it's more complex than before because of the additional version information. I've implemented the parsing for the previous ThrowableInformation for the case where the setAccessible call on throwable failed due to SecurityException but I wasn't feeling too well about that approach from the beginning. I also lost the "x common frames omitted" feature because of it, just to save some processor cycles :p My main point is that it generates additional heat. Both the creation of the ThrowableProxy and the reparsing on my side will cost some logging time. I'm also a bit wary about future changes. Those are always more time-consuming and error-prone to implement in case of string parsing than with "proper" data objects. I would like to avoid both the performance impact and the instability inherent to the parsing approach, if possible. A ThrowableProxy like class ThrowableProxy { String throwableClassName; String message; StackTraceElementProxy[] stackTrace; ThrowableProxy cause; int omittedFrames; transient String stringRep; } shouldn't mean any more work on your side (probably even a bit less) and would mean quite a bit less for me. The only downside I see right now is that the "cause" ThrowableProxy would also cache it's string representation, meaning it would cost some memory. But this could be prevented by adding a flush() method which nulls the stringRep so ThrowableProxy could call flush() on the contained cause ThrowableProxy after creation of their own stringRep. One of the use cases I have in mind is to optionally only show the top-most and/or the root cause of the exception in the details view of Lilith. Just to show you that I actually have a reason beside the xml structure... :D I really hope you can do me this favor... > ThrowableInformation should keep the Throwable cause hierarchy intact. > ---------------------------------------------------------------------- > > Key: LBCLASSIC-46 > URL: http://jira.qos.ch/browse/LBCLASSIC-46 > Project: logback-classic > Issue Type: Improvement > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Ceki Gulcu > Priority: Minor > > Instead of a String representation of the whole Throwable stack trace incl. cause ThrowableInformation should instead look like this: > public class ThrowableInformation implements Serializable > { > String throwableClassName; > String message; > StackTraceElement[] stackTrace; > ThrowableInformation cause; > } > I omitted get/set and private in this example. > StackTraceElement is perfectly Serializable and did also receive a public c'tor in Java 5 so I guess that the current ThrowableInformation is more or less a relict of log4j which had to stay compatible with older Java versions. > You could obviously keep the getThrowableStrRep() method for compatibility. > This bug is somewhat related to LBCLASSIC-45 because I think that ThrowableInformation should also, as LoggingEvent, be just a dumb data container with no real logic. > The logic to extract the relevant StackTraceElements should IMHO be moved either into Logger or into a static factory method of ThrowableInformation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBSITE-21) Quickstart section on frontpage for new people
by Thorbjoern Ravn Andersen (JIRA) 17 Nov '08

17 Nov '08

Quickstart section on frontpage for new people ---------------------------------------------- Key: LBSITE-21 URL: http://jira.qos.ch/browse/LBSITE-21 Project: logback-site Issue Type: Improvement Components: Documentation Reporter: Thorbjoern Ravn Andersen Assignee: Logback dev list The current frontpage wants to give a lot of information about logback in general. It might be beneficial to a bypassing developer to provide a "Quickstart with Logback" link one of the very first paragraphs on the front page, so that they can get a "what does it take to do this, and what benefit do I get out of it". I suggest that it basically describes how to add a "Start" and "Stop" log message to HelloWorld and briefly list where else logback can send log messages to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

pending message
by Thorbjørn Ravn Andersen 17 Nov '08

17 Nov '08

Hi Ceki. Sent a message earlier today which apparently got the wrong sender address so it awaits moderator approval. It is about AS/400 specific logback stuff. Could you have a look in the queue? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"

1 0

[JIRA] Created: (LBCLASSIC-79) NullPointerException in JMX Configurator setLoggerLevel
by Jean-Luc Geering (JIRA) 17 Nov '08

17 Nov '08

NullPointerException in JMX Configurator setLoggerLevel ------------------------------------------------------- Key: LBCLASSIC-79 URL: http://jira.qos.ch/browse/LBCLASSIC-79 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.11 Reporter: Jean-Luc Geering Assignee: Logback dev list import org.slf4j.LoggerFactory; import ch.qos.logback.classic.LoggerContext; import ch.qos.logback.classic.jmx.Configurator; import ch.qos.logback.classic.jmx.ConfiguratorMBean; public class Test { public static void main(String[] args) { LoggerFactory.getLogger("com.test1"); LoggerFactory.getLogger("com.test2"); LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); ConfiguratorMBean configurator = new Configurator(lc); configurator.setLoggerLevel("com", "info"); configurator.setLoggerLevel("com", "null"); } } Exception in thread "main" java.lang.NullPointerException at ch.qos.logback.classic.Logger.setLevel(Logger.java:193) at ch.qos.logback.classic.jmx.Configurator.setLoggerLevel(Configurator.java:92) at Test.main(Test.java:14) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 1

[JIRA] Created: (LBCLASSIC-78) NullPointerException in JMX Configurator getLoggerLevel
by Jean-Luc Geering (JIRA) 17 Nov '08

17 Nov '08

NullPointerException in JMX Configurator getLoggerLevel ------------------------------------------------------- Key: LBCLASSIC-78 URL: http://jira.qos.ch/browse/LBCLASSIC-78 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.11 Reporter: Jean-Luc Geering Assignee: Logback dev list NullPointerException in JMX Configurator getLoggerLevel: on line 111, logger.getLevel() can be null. in ch.qos.logback.classic.jmx.Configurator, lines 110 - 114, replace if (logger != null) { return logger.getLevel().toString(); } else { return EMPTY; } with if (logger != null && logger.getLevel() != null) { return logger.getLevel().toString(); } else { return EMPTY; } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Resolved: (LBCLASSIC-57) SyslogAppender fails sporadically
by Ceki Gulcu (JIRA) 17 Nov '08

17 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-57?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu resolved LBCLASSIC-57. --------------------------------- Fix Version/s: 0.9.12 Resolution: Fixed > SyslogAppender fails sporadically > --------------------------------- > > Key: LBCLASSIC-57 > URL: http://jira.qos.ch/browse/LBCLASSIC-57 > Project: logback-classic > Issue Type: Bug > Environment: $ uname -a > Linux ... 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 GNU/Linux > $ java -version > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) > multiprocessor PC box > Reporter: Anton Tagunov > Assignee: Logback dev list > Fix For: 0.9.12 > > > * several JVM-s per Linux box > * 5 SyslogAppender-s logging to syslog-ng on 127.0.0.1 > Once in a while one of the SyslogAppender-s (the busiest one with longest messages) stops logging completely > Other SyslogAppender-ss continue working fine. > /usr/sbin/tcpdump has confirmed upd packets reach > syslog-ng port via 'lo' network interface for remaining appends > /usr/sbin/tcpdump has confirmed NO udp packets reach > syslog-ng port via 'lo' network interface for the failing appender > We have JMX enabled. JConsole does show StatusManager messages. > There are no error messages there. > Just the messages emitted during initial logback configuration > from logback.xml on the classpath. > We had invoked 'reload()' method via JMX. > StatusMananger messages observed via JMX show that reload had happened. > Full re-configuration had happened. > All 5 SyslogAppenders had been apparently re-created. > Yet NO udp messages had come from the SyslogAppender > replacing those which had previously failed. > Reloading did not help at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Moved: (LBCLASSIC-87) LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++)
by Ceki Gulcu (JIRA) 17 Nov '08

17 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-87?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu moved LBCORE-24 to LBCLASSIC-87: ------------------------------------------- Project: logback-classic (was: logback-core) Key: LBCLASSIC-87 (was: LBCORE-24) Component/s: Other (was: Other) Affects Version/s: unspecified (was: unspecified) > LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++) > --------------------------------------------------------------- > > Key: LBCLASSIC-87 > URL: http://jira.qos.ch/browse/LBCLASSIC-87 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Jens Elkner > Assignee: Logback dev list > > Since LoggerFactory obtains the LoggerContext to use in its static init stage, using a LoggerContextFilter as described in Chapter 8 is completely useless, since the JNDI selector is never consulted again. > Digging deeper on that issue reveals, that using a ContextJNDISelector (even if it would work) rarely leads to the intended behavior (e.g. webapp related logging), and is probably not thread safe wrt. common practice and intended logging. E.g. in tomcat we have two different cases: > a) each webapp provides its own slfj4*.jar as well as *logback*.jar > b) slfj4*.jar as well as *logback*.jar are shared via tomcat/common/lib or > tomcat/share/lib > c) a und b mixed > Well, to get things right, one can say case c) is unsupported ;-). > In case a) logback has its own playground, so using JNDI doesn't make sense at all, since the webapp/logback has its own playground - doesn't interfere with > other web apps since loaded via its dedicated classloader. > However case b) is a little bit more challenging. Here the LoggerFactory and other classes are !shared! between several webapps, since loading is delegated from the dedicated webapp classloader to the shared webapp classloader, which picks up everything in share/lib , common/lib. So right now in 0.9.7, even if one uses JNDISelector a per webapp logging is impossible: The first webapp, which asks for a LoggerFactory always wins! All other webapps, which ask later for a LoggerFactory.getLogger() will get a Logger from the LoggerContext associated with the first webapp, since the context is "cached", i.e. the JNDI selector gets never consulted again. > Assuming the LoggerFactory problem gets fixed by using e.g. > public static Logger getLogger(* *) { > return StaticLoggerBinder.SINGLETON.getLoggerFactory().getLogger(**); > } > there is still a problem wrt. common practice aka log* usage pattern and webapp shared classes, which can not be resolved by JNDI: Today most developer use something like: > public class XY { > private static [final] Logger log = LoggerFactory.getLogger(XY.class); > ... > } > That implies the same problem, as with the current LoggerFactory bug: The class gets the Logger from the context associated with the first webapp, which needs the shared class. And that's why all other webapps, which later need this class will use the the logger context of the first webapp. So e.g. if webapp A is configured to log to /var/log/a.log and another webapp B is configured to log to /var/log/b.log the loging output of shared classes will always go to /var/log/a.log if webapp used the classes in question first, no matter on which thread aka in which webapp the shared classes are used. > So even if LoggerFactory gets fixed, JNDI selector is of little use, if one wants to have a webapp dedicated log as soon as shared classes are involved. > The only way to solve the didcated webapp log problem a can think of, to introduce another level of indirection in the Logger.log* etc. method, which takes care of thread local settings and the settings of its parent threads (e.g. an application may start other threads, which do not inherit the thread local settings from the current thread ...). But this would probably influence the performance of logback in a rather negative way. > Another idea might be an architecture re-design: sharing Loggers would be no problem because of thread local AppenderContext soft ref, which points to an Appender in the global AppenderStore singleton ... > RFE: These problems should be reflected chapter 8 of the logback manual to avoid further confusion ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCLASSIC-46) ThrowableInformation should keep the Throwable cause hierarchy intact.
by Ceki Gulcu (JIRA) 17 Nov '08

17 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBCLASSIC-46: ------------------------------------- It should be quite easy to reconstruct the original STEs. Just search for the first (or second) entry in the ThrowableDataPoint array which is a rawString.Note that I am not closing this issue. This comment is just to let you know that it can be easily done. > ThrowableInformation should keep the Throwable cause hierarchy intact. > ---------------------------------------------------------------------- > > Key: LBCLASSIC-46 > URL: http://jira.qos.ch/browse/LBCLASSIC-46 > Project: logback-classic > Issue Type: Improvement > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Ceki Gulcu > Priority: Minor > > Instead of a String representation of the whole Throwable stack trace incl. cause ThrowableInformation should instead look like this: > public class ThrowableInformation implements Serializable > { > String throwableClassName; > String message; > StackTraceElement[] stackTrace; > ThrowableInformation cause; > } > I omitted get/set and private in this example. > StackTraceElement is perfectly Serializable and did also receive a public c'tor in Java 5 so I guess that the current ThrowableInformation is more or less a relict of log4j which had to stay compatible with older Java versions. > You could obviously keep the getThrowableStrRep() method for compatibility. > This bug is somewhat related to LBCLASSIC-45 because I think that ThrowableInformation should also, as LoggingEvent, be just a dumb data container with no real logic. > The logic to extract the relevant StackTraceElements should IMHO be moved either into Logger or into a static factory method of ThrowableInformation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Resolved: (LBCORE-16) TimeBasedRollingPolicy with MinIndex and MaxIndex attributes
by Ceki Gulcu (JIRA) 17 Nov '08

17 Nov '08

[ http://jira.qos.ch/browse/LBCORE-16?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu resolved LBCORE-16. ------------------------------ Fix Version/s: 0.9.11 Resolution: Fixed Fixed as part of LBCORE-11. See also the MaxHistory property in TimeBasedRollingPolicy: http://logback.qos.ch/xref/ch/qos/logback/core/rolling/TimeBasedRollingPoli… > TimeBasedRollingPolicy with MinIndex and MaxIndex attributes > ------------------------------------------------------------ > > Key: LBCORE-16 > URL: http://jira.qos.ch/browse/LBCORE-16 > Project: logback-core > Issue Type: Improvement > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Keith > Assignee: Logback dev list > Priority: Minor > Fix For: 0.9.11 > > > It would be useful for keeping the rolling number of compressed logs with such parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Resolved: (LBCLASSIC-33) unregistering in the jmx plugin
by Ceki Gulcu (JIRA) 17 Nov '08

17 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-33?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu resolved LBCLASSIC-33. --------------------------------- Fix Version/s: 0.9.12 Resolution: Fixed > unregistering in the jmx plugin > ------------------------------- > > Key: LBCLASSIC-33 > URL: http://jira.qos.ch/browse/LBCLASSIC-33 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Hontvári József > Assignee: Ceki Gulcu > Fix For: 0.9.12 > > > I started using the JMX plugin of login, and I wondered how should I > shut it down when a web application is restarted. I haven't found a > function which unregisters the Configurator MBean. This object holds a > reference (through ContextAwareBase) to a Context. I am afraid that not > unregistering it causes a memory leak when a web application is restarted. > There should be a way to shutdown the JMX plugin. Or more generally an API to shut down the Logback system in its entirety: flush buffers, close files etc. It must be decided what to do if a log request arrives when or after logback is shutting down. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0