May 2007 - logback-user - mailman3.qos.ch

An OSGi bundle for logback?
by John E. Conlon 14 Sep '07

14 Sep '07

Are there any plans for a logback OSGi bundle in the foreseeable future? ;-)

3 3

NullPointer in PropertySetter.computeContainmentTpye
by mancereus 19 Jul '07

19 Jul '07

The follwoing logback.xml works with tomcat, but not in orion application server: <?xml version="1.0" encoding="UTF-8" ?> <configuration> <appender name="ROLLFILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${LOG_HOME}xsvapp.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <param name="FileNamePattern" value="${LOG_HOME}xsvapp.log.%d{yyyy-MM-dd}" /> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <param name="Pattern" value="%d{HH:mm:ss} %-5level [%thread] %class{25} - %msg%n" /> </layout> </appender> <root> <level value="debug" /> <appender-ref ref="ROLLFILE" /> </root> </configuration> I get the following NPE: 04.05.07 11:00 ixmidixservweb: Error initializing servlet java.lang.ExceptionInInitializerError at com.ixmid.ixservweb.web.session.SmnResolveProxies.<clinit>(SmnResolveProxies.java:117) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at com.evermind._ay._lse(Unknown Source) at com.evermind._ay._cbd(Unknown Source) at com.evermind._ay._lze(Unknown Source) at com.evermind._ay._lme(Unknown Source) at com.evermind._ay.<init>(Unknown Source) at com.evermind._am._rvb(Unknown Source) at com.evermind._ex._rvb(Unknown Source) at com.evermind._eu._kie(Unknown Source) at com.evermind._eu._bi(Unknown Source) at com.evermind._ex._bn(Unknown Source) at com.evermind._ex._bi(Unknown Source) at com.evermind.server.ApplicationServer._gse(Unknown Source) at com.evermind.server.ApplicationServer._bi(Unknown Source) at com.evermind._csb.run(Unknown Source) at java.lang.Thread.run(Thread.java:619) at com.evermind._bf.run(Unknown Source) Caused by: java.lang.NullPointerException at ch.qos.logback.core.util.PropertySetter.computeContainmentTpye(PropertySetter.java:234) at ch.qos.logback.core.util.PropertySetter.canContainComponent(PropertySetter.java:207) at ch.qos.logback.core.joran.action.NestedComponentIA.isApplicable(NestedComponentIA.java:57) at ch.qos.logback.core.joran.spi.Interpreter.lookupImplicitAction(Interpreter.java:214) at ch.qos.logback.core.joran.spi.Interpreter.getApplicableActionList(Interpreter.java:233) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:122) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:110) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:36) at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:336) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:96) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:74) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:38) at com.ixmid.bas.BasLog4j.<clinit>(BasLog4j.java:68) ... 19 more any idea? (the "normal" FileAppender works with both tomcat and orion) -- View this message in context: http://www.nabble.com/NullPointer-in-PropertySetter.computeContainmentTpye-… Sent from the Logback User mailing list archive at Nabble.com.

2 7

Unable to use ContextSelector
by Leonardo de Moura Rocha Lima 30 May '07

30 May '07

Hello, all. I've been trying to use a ContextSelector to achieve the behavior of JNDIContextSelector, but replacing JNDI lookups with MDC.get(). It did work and now I can have a new LoggerContext based on MDC. That way, I can have new configuration options based on MDC variables. I changed the StaticLoggerBinder implementation to use this new ContextSelector and the first context is correctly get and used. The problem that is stopping my progress is that I can't get to use more than one context. The StaticLoggerBinder.getLoggerFactory() is called once, and only once: in startup. After that, I can't change the ILoggerFactory that's inside the LoggerFactory, because it's static and only set in static { }. That way, when I need to switch contexts, even if I change the current context inside the ContextSelector, it won't be used by the LoggerFactory. I even reproduced the calls from ContextSelectorFilter so that I set/unset the current context, but no use. I thought about using a wrapper ILoggerFactory, but it feels wrong, because the JNDIContextSelector doesn't use anything else and is supposed to work. What am I doing wrong? How do I use ContextSelectors outside what's mentioned in logback manual? Leonardo de Moura Rocha Lima 55 11 3094.3939

1 0

DBAppender with ConnectionPool
by Klaus UNGER 30 May '07

30 May '07

Hello, I do have a "funny" problem - so far my understanding ... I have successfully configured LogBack and SLF4J with an DBAppender I have clients which do their logging via SocketAppender to a LogServer, which is intended to write the messages to the database. Everything (except Exceptions and MDC - see former posts) works fine, but when I added C3P0 Connection Pooling to the appender, like shown in the documentation and the examples, I do get the following StackTrace: java.lang.ExceptionInInitializerError at com.mchange.v2.naming.JavaBeanReferenceMaker.<clinit>(JavaBeanReferenceMaker.java:39) at com.mchange.v2.c3p0.impl.PoolBackedDataSourceBase.<clinit>(PoolBackedDataSourceBase.java:203) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at ch.qos.logback.core.joran.action.NestedComponentIA.begin(NestedComponentIA.java:107) at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:259) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:126) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:110) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:36) at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:336) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:96) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:74) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:38) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:24) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:35) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:46) at org.slf4j.impl.StaticLoggerBinder.initialize(StaticLoggerBinder.java:52) at org.slf4j.impl.StaticLoggerBinder.<init>(StaticLoggerBinder.java:44) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:39) at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:57) at com.mobilkom.cusi.logging.LoggingServer.<clinit>(LoggingServer.java:13) Caused by: java.lang.IllegalStateException: Logging factory implementation cannot be null. See also http://www.slf4j.org/codes.html#null_LF at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:75) at org.apache.log4j.Category.<init>(Category.java:52) at org.apache.log4j.Logger.<init>(Logger.java:22) at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:38) at org.apache.log4j.Category.getLogger(Category.java:56) at org.apache.log4j.Category.getLogger(Category.java:60) at com.mchange.v2.log.log4j.Log4jMLog.getMLogger(Log4jMLog.java:51) at com.mchange.v2.log.MLog.getLogger(MLog.java:145) at com.mchange.v2.log.MLog.<clinit>(MLog.java:72) For me, it looks like, while Configuring the LogServer, the Systems tries to instantiate the DBAppender, which itself tries to setup the connection-pool which has some logging statements inside it's C3P0-CodeBase. The LoggingSystem is yet not properly initialized (Logging factory implementation cannot be null. See also http://www.slf4j.org/codes.html#null_LF) looks like "the cat is chasing it's tail" ... any ideas, hints, explanations, etc. - greatly welcome kind regards Klaus :)

1 0

DBAppender Configuration Example
by Klaus UNGER 30 May '07

30 May '07

Hello, is there a configuration example, how one can use DBAppender for writing events in an Oracle DB (see "Bug 57") I tought, maybe the explizit usage of SQLDialect for Oracle would propably "solve" the problem ... but I didn't find an example, how to configure the explizit usage of an SQLDialect. any hints highly appreciated kind regards K:) Unger --------------------- Klaus UNGER, BSc Münzgasse 3/40+42 A-1030 Wien mobil: +43 (664) 4236046

1 0

Release of version 0.9.7
by Ceki Gulcu 29 May '07

29 May '07

29th of May 2007 - Release of version 0.9.7 This release corrects packaging bugs 75 and 76 related to the migration of logback to SLF4J version 1.4.0. There are no other changes. You can download the modules, including full source code, class files and documentation on our download page, shown below. http://logback.qos.ch/download.html You can receive logback related announcements by subscribing to the logback announce mailing list. To subscribe to logback-announce list, please visit the following URL. http://logback.qos.ch/mailinglist.html -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

1 0

ENC: RES: Implementing MultiFileAppender
by Leonardo de Moura Rocha Lima 29 May '07

29 May '07

Hello, all. First let me introduce myself. I'm Leonardo Lima, and I've been using log4j for about 2 years. In the past, I needed to generate one log file per 'context', context being anything that I put in my MDC. I went to the log4j user list, discussed a little with other users and I used an implementation that I found at log4j bug tracking system. I've been using it since October last year and it's all ok. Sebastien contacted me and the other guys that were talking about (how to) implementing what became the MultiFileAppender so that we could contribute it to logback; but at the time I couldn't switch to nor learn logback. Now I want to use logback and reproduce the functionality of MultiFileAppender (that I went and improved myself over). So, the result's in the emails that follows. So, please, any input/feedback is much welcome. I improved the code below using EHCache as caching solution to handle the timeout/max open files problems that would occour, but maybe something simpler and built-in is better. And, as an improvement, I thought about applying the whole PatternLayout parsing to filenames, so we could use thread names and much more information on file names. That and the option to auto-create dirs, would be awesome (at least for me). Think about self-organizing log! Thanks a lot for your time. Leonardo de Moura Rocha Lima -----Mensagem original----- De: Ceki Gulcu [mailto:ceki@qos.ch] Enviada em: terça-feira, 29 de maio de 2007 15:25 Para: Leonardo de Moura Rocha Lima Cc: 'Sebastien Pennec' Assunto: Re: RES: Implementing MultiFileAppender Hello Leonardo, Since this conversation might interest other users, could you please post your message on the logback-user mailing list? Many thanks, Leonardo de Moura Rocha Lima wrote: > Hello, Sebastien. > > I'm sorry that it took such a long time to reply your e-mail, but only now I > got 'green light' to go into logback. We now have a new project that we'd > like to use logback and keep the MultiFileAppender behavior (developed > in-house) that we had in log4j. > For what I gathered, the concept of using MDC properties in filenames isn't > yet implement in logback. So, I am on my way to implement it. > > I tried for a couple of hours to understand and use your recommendation > about using Joran replay functionality to achieve what we need, but failed. > I did run and (I think I) understood the FruitConfigurationTest. I read > Chapter 3 of the logback Manual that has an example of using Joran to > re/load configuration. But I failed to understand how I replay the > configuration once the first run is running. > > So I went and did something that's not that beautiful, but works. I > implemented an Appender has a parser that substitutes the %X{} and %d{} tags > (not recursively, but more than one tag per filename. Example: > client.%X{ip}.%X{port}.%d{yyyy}.%d{MM}.log) and create a new filename from a > base filename, plus a map of FileAppenders to delegate the logging events > to. It's a naïve approach, but it's suiting my needs (use MDC to generate > context, roll logger using Time). Only thing left is handling appenders > 'timeout' and 'max open files', so I don't get too many file handles nor > keep file handles open for no reason. I thought about using some cache > solution to handle that, but it would add more dependency to the project... > > I'd like to request your guidance on the matter. Should I go on with what I > wrote (with or without the cache), or please teach me how the 'replay' > functionality would be used in this matter. And, if I wanted to contribute > the code, what should I provide. I've never contributed anything before... > > I embed the code of my class here because I don't know how you handle > attachments... > > Thanks in advance, and keep up the good work on logback. > > Leonardo de Moura Rocha Lima > 55 11 3094.3939 > > > import java.text.SimpleDateFormat; > import java.util.Date; > import java.util.HashMap; > import java.util.Map; > > import ch.qos.logback.classic.spi.LoggingEvent; > import ch.qos.logback.core.AppenderBase; > import ch.qos.logback.core.FileAppender; > import ch.qos.logback.core.Layout; > > public class LAppender extends AppenderBase<LoggingEvent> { > > /** > * Base Filename. Will be parsed for %X{} and %d{} tags. > */ > private String file; > > /** > * FileAppender option; will propagate. > */ > private Layout<LoggingEvent> layout; > > /** > * FileAppender option; will propagate. > */ > private boolean immediateFlush = true; > > /** > * FileAppender option; will propagate. > */ > private boolean bufferedIO; > > /** > * FileAppender option; will propagate. > */ > private String encoding; > > /** > * FileAppender option; will propagate. > */ > private boolean append; > > /** > * FileAppender option; will propagate. > */ > private int bufferSize; > > /** > * Map of current active FileAppenders. Needs improvement: max open > files > * and timeout, to keep resources > */ > private Map<String, FileAppender<LoggingEvent>> appenders = new > HashMap<String, FileAppender<LoggingEvent>>(); > > /** > * Return the FileAppender for the given filename. Create a new one > and add > * to cache, if needed. > */ > private FileAppender<LoggingEvent> getFA(String filename) { > if (appenders.get(filename) != null) { > return appenders.get(filename); > } > > FileAppender<LoggingEvent> resp = new > FileAppender<LoggingEvent>(); > resp.setAppend(append); > resp.setBufferedIO(bufferedIO); > resp.setBufferSize(bufferSize); > resp.setContext(this.getContext()); > resp.setEncoding(encoding); > resp.setFile(filename); > resp.setImmediateFlush(immediateFlush); > resp.setLayout(layout); > resp.setName(this.getName()); > resp.start(); > appenders.put(filename, resp); > return resp; > } > > @Override > /** > * Delegate the LoggingEvent to the right FileAppender > */ > protected void append(LoggingEvent eventObject) { > getFA(getFile(eventObject)).doAppend(eventObject); > } > > /** > * Return the filename for the given LoggingEvent, based on the base > * filename. > */ > private String getFile(LoggingEvent eventObject) { > return substituteDate(substituteContext(file, eventObject > .getMDCPropertyMap()), new > Date(eventObject.getTimeStamp())); > } > > /** > * Parse and replace %X{} tags. > */ > private String substituteContext(String base, Map<String, String> > mdc) { > if (base == null) > return null; > if (mdc == null) > return base; > > int idx = base.indexOf("%X{"); > if (idx < 0) > return base; > int lidx = base.indexOf('}', idx); > String str = base.substring(idx + 3, lidx); > String val = mdc.get(str); > if (val == null) > val = "null"; > return substituteContext(base.replaceAll("\\%X\\{" + str + > '}', val), > mdc); > } > > /** > * Parse and replace %d{} tags. > */ > private String substituteDate(String base, Date dt) { > if (base == null) > return null; > if (dt == null) > dt = new Date(); > > int idx = base.indexOf("%d{"); > if (idx < 0) > return base; > int lidx = base.indexOf('}', idx); > String str = base.substring(idx + 3, lidx); > String val = new SimpleDateFormat(str).format(dt); > if (val == null) > val = "null"; > return substituteDate(base.replaceAll("\\%d\\{" + str + '}', > val), dt); > } > > @Override > /** > * Propagate the stop action to everyone > */ > public void stop() { > for (FileAppender<LoggingEvent> fa : > this.appenders.values()) { > fa.stop(); > } > } > > public void setFile(String file) { > this.file = file; > } > > public void setLayout(Layout<LoggingEvent> layout) { > this.layout = layout; > } > > public void setAppend(boolean append) { > this.append = append; > } > > public void setBufferedIO(boolean bufferedIO) { > this.bufferedIO = bufferedIO; > } > > public void setEncoding(String encoding) { > this.encoding = encoding; > } > > public void setImmediateFlush(boolean immediateFlush) { > this.immediateFlush = immediateFlush; > } > > public void setBufferSize(int bufferSize) { > this.bufferSize = bufferSize; > } > > } > > > -----Mensagem original----- > De: Sebastien Pennec [mailto:sebastien@qos.ch] > Enviada em: segunda-feira, 23 de outubro de 2006 14:53 > Para: HBender(a)Ergonomics.ch; Patrick.Wyss(a)mobilesolutions.ch; online(a)l3o.net > Cc: Ceki Gülcü > Assunto: Implementing MultiFileAppender > > Hello Heri and Leo and Patrick, > > You might have heard of logback, a rewrite of log4j by Ceki Gülcü, log4j's > founder. > Logback has a smaller memory footprint and is faster by a wide margin. It > has much > better error reporting capability and is generally more robust. Logback has > support > for markers which enables capabilities not found elsewhere. We will be > documenting > these capabilities in the near future. > > We've read your mails on the log4j mailing list about a MultiFileAppender, > and found > your idea very interesting. > > In logback, there is mostly all the bricks one might need to create such a > component. > > Our new version of the Joran configuration framework allows replay of > configuration > elements. This is exactly what's needed to create new FileAppenders based on > specific > situations. When replaying configuration sequences, one can replace some > properties, > such as file name, to fine tune the new component. > > For documentation about Joran, you might want to check the following > resources > > - http://logback.qos.ch/joran.html > - logback-core/examples/src/joran/ (available from Subversion repo) > - ch.qos.logback.core.joran.replay.FruitConfigurationTest (Subversion repo) > > Replay functionality in Joran is only available from the Subversion repo. It > will be > included in logback version 0.5. > > Regarding FileAppender and derived appenders, logback has similar support > compared to > log4j 1.3, in addition to several niceties. > > Would you like to contribute MultiFileAppender to logback? If you are > interested, we > will gladly provide support for this endeavor. > > Kind regards, > > Sébastien > -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

1 0

log4j xml configuration translator
by Arthur Blake 24 May '07

24 May '07

The log4j to logback properties translator (at http://logback.qos.ch/translator/Welcome.do) looks like it could be very useful for those migrating from log4j to logback. However, I do all of my log4j configuration with xml (DomConfigurator). What do you think about adding a logback translator for that as well on the web site? thanks Arthur Blake ____________________________________________________________________________________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

1 0

Release of version 0.9.6
by Ceki Gulcu 24 May '07

24 May '07

23rd of May 2007 - Release of version 0.9.6 Logback is now aligned and compatible with SLF4J version 1.4.0, thus correcting bug 73 as reported by Andy Gerweck. Fixed NoClassDefFoundError problem when running under JDK 1.4 as reported by Brian Suksomwong. Fixed bug 63 as reported by La Canea Rosario. Calling log4j (bridge) with the trace level will no longer cause an IllegalStateException to be thrown. Fixed bug 70 as reported by Dirk Ooms. The %throwable conversion word is now recognized as documented in the logback manual. Moreover, the manual now mentions the %nopex word which can be used to force PatternLayout to ignore the exception contained in the logging request. As in most releases, the documentation has been improved. You can download the modules, including full source code, class files and documentation on our download page, shown below. http://logback.qos.ch/download.html You can receive logback related announcements by subscribing to the logback announce mailing list. To subscribe to logback-announce list, please visit the following URL. http://logback.qos.ch/mailinglist.html -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

1 0

Question about the right way to provide Standard MDC Entries for every call while using LogBack ...
by Klaus UNGER 24 May '07

24 May '07

Hello everybody, So far, many thanks for the great work, already done! We are using SLF4J and LogBack in an large Eclipse RCP Client/Server project for our logging purposes. During one of our last design sessions, we were discussing the options, how to deal with standard operations while logging. In detail, every of our RCP Clients is logging towards a central LogServer and we have a business requirement for putting the authenticated User as well as some other detail information into the MDC and pass it along with every single LOGGER-call. I've searched a bit and didn't find direct support for that demands. Any hints how to solve such a requirement properly or pointers in the right direction towards documentation, etc. would be greatly appreciated. BTW ... any news/updates regarding "BUG 57" http://bugzilla.qos.ch/show_bug.cgi?id=57 Are there any plans to support JDK 1.5 variable param lists in LogBack-Logger instead of Object[]? Are there any plans to extend the Logger-Calls for Throwable to support also formatted messages? Many thanks in advance for your help kind regards from sunny Vienna K:) --------------------- Klaus UNGER, BSc Münzgasse 3/40+42 A-1030 Wien mobil: +43 (664) 4236046

1 0