March 2011 - logback-user - mailman3.qos.ch

Custom appender: no stack traces?
by Christopher Piggott 08 Mar '11

08 Mar '11

Hi, I wrote a custom appender that just writes to a circular queue: public class MemoryAppender extends AppenderBase<ILoggingEvent> { stuff } I configure it as follows: <appender name="ringLogger" class="com.xxxxxxxx.MemoryAppender"> <limit>1000</limit> </appender> His append NEVER receives stack traces: public void add(ILoggingEvent loggingEntry) { boolean hasStackTrace = loggingEntry.getCallerData(); /* always false ! */ } Any idea why this would be? This appender is just about as simple as it can get ...... --Chris

2 2

RollingFileAppender with compress & %i
by DeepakVadgama 05 Mar '11

05 Mar '11

FixedWindowRollingPolicy with compress and %i, always zips the active log file and renames the zip Thus The log files inside all the resulting zips has same log filename. How do i ensure the log file is renamed with %i before zipping it up? Eg: FileNamePattern of MyLogFile%i.log.zip currently results in MyLogFile1.log.zip (with log file name MyLogFile.log) MyLogFile2.log.zip (with log file name MyLogFile.log) MyLogFile3.log.zip (with log file name MyLogFile.log) I want it to be MyLogFile1.log.zip (with log file name MyLogFile1.log) MyLogFile2.log.zip (with log file name MyLogFile2.log) MyLogFile3.log.zip (with log file name MyLogFile3.log) -- View this message in context: http://old.nabble.com/RollingFileAppender-with-compress----i-tp31037552p310… Sent from the Logback User mailing list archive at Nabble.com.

4 4

Programmatically adding appenders
by Jason Corbett 04 Mar '11

04 Mar '11

I have searched, but have been unable to find a way to do this. I need to add an appender after configuration has happened. This is because whether or not the appender is even wanted is dependent on a runtime condition. I've seen plenty of examples using the sifting appender, but I don't want to include the appender in the config file because I don't want to create a dependency on the appender being there (it's an optional component). I've tried this: LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); Logger testcase_logger = lc.getLogger("test"); logAppender.setContext(testcase_logger.getLoggerContext()); testcase_logger.addAppender(logAppender); But I never get any logging events (this is a custom log appender). Test is the base of all the loggers I want logging to this appender (I want anything with a test. at the beginning of the logger name to write to this appender). Any ideas? My custom appender extends AppenderBase<ILoggingEvent>. Jason Corbett

2 2

Logback.groovy configuration results in java.lang.VerifyError exception.
by rathnadhar.kolar＠wipro.com 02 Mar '11

02 Mar '11

Namasthe, I have switched from log4j to logback. For configuration, I initially worked with logback.xml which worked fine. I wanted to get rid of xml so re-wrote the logback.xml in groovy. The logback.groovy is as below: import ch.qos.logback.classic.PatternLayout import ch.qos.logback.classic.filter.ThresholdFilter import ch.qos.logback.classic.net.SMTPAppender import ch.qos.logback.core.ConsoleAppender import ch.qos.logback.core.rolling.FixedWindowRollingPolicy import ch.qos.logback.core.rolling.RollingFileAppender import ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy import static ch.qos.logback.classic.Level.ERROR import static ch.qos.logback.classic.Level.INFO appender("RootFileAppender", RollingFileAppender) { file = "project" append = true filter(ThresholdFilter) { level = INFO } rollingPolicy(FixedWindowRollingPolicy) { fileNamePattern = "project_log.%i" maxIndex = 1 } triggeringPolicy(SizeBasedTriggeringPolicy) { maxFileSize = 1000000 } layout(PatternLayout) { pattern = "%d{yyyy-MM-dd HH:mm:ss}, %p, %c, %t, %ex, %F, %L, %C{1}, %M %m%n" } } appender("RootConsoleAppender", ConsoleAppender) { filter(ThresholdFilter) { level = INFO } layout(PatternLayout) { pattern = "%d{yyyy-MM-dd HH:mm:ss}, %p, %c, %t %m%n" } } appender("RootEmailAppender", SMTPAppender) { filter(ThresholdFilter) { level = ERROR } bufferSize = 10 SMTPHost = "smtp.hostaddress" to = "logback.user(a)xyz.com" from = " logback.user(a)xyz.com " username = "user" password = "password" subject = "Logback Error" layout(PatternLayout) { pattern = "%d{yyyy-MM-dd HH:mm:ss}, %p, %c, %t, %ex, %F, %L, %C{1}, %M %m%n" } } root(INFO, ["RootFileAppender", "RootConsoleAppender", "RootEmailAppender"]) (Some values have been masked for security reasons). I put this file in the classpath. After that I started my application, but I got this exception: Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: java.lang.VerifyError: (class: groovy/runtime/metaclass/java/lang/StringMetaClass, method: super$2$invokeMethod signature: (Ljava/lang/Class;Ljava/lang/Object;Ljava/lang/String;[Ljava/lang/Object ;ZZ)Ljava/lang/Object;) Illegal use of nonvirtual function call at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLo okup(MetaClassRegistry.java:127) at groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRe gistry.java:122) at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo .java:165) at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:195 ) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass (MetaClassRegistryImpl.java:214) at org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.jav a:747) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createPojoSite(CallSi teArray.java:107) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSi teArray.java:148) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteA rray.java:40) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallS ite.java:116) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallS ite.java:124) at ch.qos.logback.classic.gaffer.ConfigurationDelegate.appender(Configurati onDelegate.groovy:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at org.codehaus.groovy.runtime.metaclass.MixinInstanceMetaMethod.invoke(Mix inInstanceMetaMethod.java:53) at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSi teNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:307) at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(Pogo MetaMethodSite.java:51) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(Ca llSiteArray.java:44) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(Abstra ctCallSite.java:141) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(Abstra ctCallSite.java:157) at Script1.run(Script1.groovy:24) at Script1$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteA rray.java:40) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallS ite.java:116) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallS ite.java:120) at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator. groovy:59) at ch.qos.logback.classic.gaffer.GafferConfigurator$run.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(Ca llSiteArray.java:44) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(Abstra ctCallSite.java:141) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(Abstra ctCallSite.java:149) at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator. groovy:37) at ch.qos.logback.classic.gaffer.GafferUtil.runGafferConfiguratorOn(GafferU til.java:44) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(Conte xtInitializer.java:67) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitial izer.java:150) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241) at src.temporalprocessing.StartProgram.<clinit>(StartProgram.java:37) When I switch from logback.groovy to logback.xml, everything works perfectly (both the configurations are equal in functionality). My google search did not yield useful information. I am using the following jars: 1. groovy-all-1.7.8.jar 2. logback-access-0.9.28.jar 3. logback-classic-0.9.28.jar 4. logback-core-0.9.28.jar 5. slf4j-api-1.6.1.jar Can somebody please help me to resolve the issue. Regards Rathnadhar.K.V Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

2 9

MDC bug in 0.9.28
by Becker, Thomas 01 Mar '11

01 Mar '11

FYI, I just opened http://jira.qos.ch/browse/LBCLASSIC-253 regarding modifications to a child thread's MDC affecting the parent thread. It looks like LogbackMDCAdapter.clear() incorrectly calls clear() on the HashMap before removing the ThreadLocal. This is bad because the map is still potentially shared with the parent thread at that point. Regards, Tommy

1 0

Re: [logback-user] MDC and env-entry
by José Juan Montiel 01 Mar '11

01 Mar '11

Hi, You could easyly write your own discriminator class combining > JNDIBasedContextDiscriminator and MDCBasedDiscriminator. Here is an > example: > > public class CombinedDiscriminator extends ContextAwareBase implements > Discriminator<ILoggingEvent> { > > private String defaultMDCVal = "default"; > > public String getDiscriminatingValue(ILoggingEvent event) { > String mdcValue = defaultMDCVal; > Map<String, String> mdcMap = event.getMdc(); > if (mdcMap != null) { > mdcValue = mdcMap.get(key); > } > String contextName = event.getLoggerContextVO().getName(); > return contextName + mdcValue; > } > ..etc > } > > Thanks for reply, i started to implement, but i noticed that maybe i don't explain well, i dont need "sumValue = contextName + mdcValue" value to use in <FileNamePattern>${newValue}.log</FileNamePattern> That i really need is two values... contextName and mdcValue... The aprox, maybe something like <FileNamePattern>${newValue.substring(0,x)}/${newValue.substring(x,n)}.log</FileNamePattern> or something like <appender ... class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> ... <sift> <appender ... class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> ... <sift> <appender class="ch.qos.logback.core.rolling.RollingFileAppender"> SiftingAppender inside SiftingAppender to use MDC and contextName. Any suggestion? And thanks again. -- Jose Juan Montiel Martinez Eurobits Technologies Calle Musgo 3, 1ª Planta 28023 Madrid T +34-917080300 F +34-913077480 josejuan.montiel(a)eurobits.es http://www.eurobits.com

1 0

Re: [logback-user] Limiting events to one thread in email
by Benoit Xhenseval 01 Mar '11

01 Mar '11

Thanks Ceki, I had a look at this and I'm not too sure if it is the best approach or actually feasible... Allow me to give a few more details. 1) We're using the AsyncAppender as per http://jira.qos.ch/browse/LBCORE-92 (by the way, it would be great to include this in an official release!) 2) The processing can happen from a JMS Message or an RMI call, or a GUI event... there is no real single entry point where I would be able to put a value in MDC... Would a Cyclic Buffer per thread name in each event be a more appropriate approach? What do you think? I'm not sure we could use Thread.currentThread().getName() to distinguish each caller as the AsyncAppender would be using their own thread and not the one that actually originated the event... In which case, the interface get() on the CyclicBuffer is not suitable since I would have no way to give it the name of the thread that called the Error... Your opinion/suggestion/solution are appreciated, Thanks Benoit ----- Have a look at http://logback.qos.ch/recipes/emailPerTransaction.html HTH, -- Ceki On 17.02.2011 15:49, Benoit Xhenseval wrote: > Hi *, > > We're running an application on large multi-threaded servers. When an > exception/error occurs, we send an email with the last 50 DEBUG entries > or so. > > How could we ensure that these 50 entries are limited to the Thread that > is actually sending the error email? > > If there is no such implementation, what would be the recommended way? > > We can probably contribute it back to the community > > Many thanks > > Benoit > -- IMPORTANT NOTICE This communication contains information that is considered confidential and may also be privileged . It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender and delete the original.

2 3