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

Logback - adding appenders
by Jan Moravec 15 May '12

15 May '12

Hi, I am building a JVM agent that needs to programmatically register a logback appender to intercept logging messages from a web-application(s) running on the given JVM. By using the JVM agent I can avoid modifying the web-application's code & configuration. To make this work, I need to use byte-code instrumentation and in the class-loading phase modify some logback class(es) and inject my code that instantiates my (interception) appender and adds it to list of appenders associated with the root logger. What would be the best logback API class and method to instrument? Ideally it should be a class and method that: . Is called once upon every logback (re)initialization . Has been present in older logback versions. . Is public, stable and is not likely to disappear in future logback releases. Thank you, Jan

2 2

Re: [logback-user] syslogappender stacktraces get cut
by Ingebrigt Berg 15 May '12

15 May '12

Hi ! We have looked more into this issue. >From a TCPdump for the traffic between the app (using logback) and the syslog-server we learn that each line in the stacktrace is actually sent as a separate message to syslog (sensitive info replaced with xx/yy/zz): 11:28:37.911604 IP xx localhost.localdomain.55934 > localhost.localdomain.syslog: [bad udp cksum af4f!] SYSLOG, length: 101 Facility local3 (19), Severity error (3) Msg: Mar 30 11:28:37 yy2-31 zz-mce-test 30.03.2012 11:28:37.910 [ERROR] [LogbackTester] []: Fjas\0x0a 11:28:37.912028 IP xx localhost.localdomain.55934 > localhost.localdomain.syslog: [bad udp cksum 6076!] SYSLOG, length: 104 Facility local3 (19), Severity error (3) Msg: Mar 30 11:28:37 yy2-31 \0x09at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) The first packet is a regular log statement, the second one is a line in a stack trace. Notice how 'zz-mce-test 30.03.2012 11:28:37.910 [ERROR] [LogbackTester] []:' is replaced with: '\0x09at' If we interpret this correctly, SyslogAppender will log the error message and each StackTraceElement separately. But for the StackTraceElements it will ignore what we configure in the <SuffixPattern> property: ( <SuffixPattern>%contextName %d{dd.MM.yyyy HH:mm:ss.SSS} [%p] [%c{1}] [%X{ThreadId}]: %m%n</SuffixPattern> ) Instead the stackline messages simply get a '\0x09at' (a TAB) appended in place of the SuffixPattern. This happens in line 89 in ch.qos.logback.classic.net.SyslogAppender: sb.append(prefix).append(CoreConstants.TAB).append(step); Contrast that to line 59 in ch.qos.logback.classic.net.SyslogAppender (normal messages), where the SuffixPattern gets added: fullLayout.setPattern(prefixPattern + suffixPattern); We see two viable solutions: EITHER: when a message is split into a main message and StackTraceElements, the StackTraceElement messages must also get the content of the <SuffixPattern> appended OR: an optional property <StackTraceSuffixPattern> could be added to SyslogAppender, allowing control of what goes into StackTraceElement messages. cheers, Ingebrigt Berg + Marius Eikenes Den 11:40 20. mars 2012 skrev Ingebrigt Berg <ingebrigt(a)jpro.no> følgende: > Hi ! > > We've recently made the switch from Log4j to Logback. We use Syslog to > send logfiles to our logserver, and things generally work. > > But when there are stacktraces in the logs we get in trouble. > SyslogAppender will replace lineshifts with '#011' to make the logentry a > single line. Then it will cut each line that is to long according to the > syslog limit of 2K/line. Only the fist segment will arrive in the correct > log. The remaining segments are not prefixed with everything in the > suffixPattern, and our regexp will not have anything to match. The segment > will end up in a 'trash' log for unmatchable loglines. > > My config for the SyslogAppender looks like this: > > <contextName>company-${CONTEXT_PATH}-${environment}</contextName> > <appender name="LOGSERVER_FILE" > class="ch.qos.logback.classic.net.SyslogAppender"> > <syslogHost>localhost</syslogHost> > <facility>local3</facility> > <SuffixPattern>%contextName %d{dd.MM.yyyy HH:mm:ss.SSS} [%p] > [%c{1}] [%X{ThreadId}]: %m%n</SuffixPattern> > </appender> > > We use the contextName property to control the logfilename. On the > receiving end we read the contextName parameter (using a regexp) for each > log line, and write the line to a file with a corresponding name. > > We had a similar problem when we used Log4J (Where the Tag element was > used in the same manner), and fixed it back then by writing a custom log4j > SyslogAppender. But the main purpose of moving to Logback is to loose all > our home brew logging stuff, we don't want to go down that path again. If > we can't make Logback work out of the box with Syslog we'll probably end up > going back to Log4J. (Another alternative is to replace Syslog with Gelf, > but that's further down the road). > > However, I imagine Logback and Syslog being a common combination, and > surely someone must have this working out of the box. Any advice will be > appreciated. My requirements are simple: > -must work with no custom logging code, only config (preferably xml) > -stacktraces in logs must work > -must be able to fully control the filename on the recieving end. > > cheers, > Ingebrigt Berg >

2 7

Applying a layout for a JMSQueueAppender
by Aakash 11 May '12

11 May '12

I m using a JMS appender to write to a JMS queue.However, when I specify a layout for the Appender it is not being considered. Is there a way to make the JMS appender use the Layout class specified?

1 0

QOS.ch JIRA server successfully upgraded
by ceki 10 May '12

10 May '12

Hi All, FYI, the Jira server for the logback project has been successfully upgraded to Jira version 5. If you encounter any problems potentially related to this upgrade, please let me know. Cheers, -- Ceki http://twitter.com/#!/ceki

1 0

QOS.ch JIRA server going down for maintenance
by ceki 10 May '12

10 May '12

Hi All, For maintenance reasons, our JIRA server located at http://jira.qos.ch/ will be shutdown for a few hours. Cheers, -- Ceki http://twitter.com/#!/ceki

1 0

QOS.ch JIRA server going down for maintenance
by ceki 10 May '12

10 May '12

Hi All, For maintenance reasons, our JIRA server located at http://jira.qos.ch/ will be shutdown for a few hours. Cheers, -- Ceki http://twitter.com/#!/ceki

1 0

Logback configuration per jar file
by Jonathan Barbero 09 May '12

09 May '12

Hello, I'm trying to figure how to let each jar file has its own logback configuration. I had an idea but is a little complicated and probably will have problems in different contexts. http://stackoverflow.com/questions/10505674/logback-configuration-files-per… Did somebody try this? Any hint or idea is welcome. Thanks in advance, Jonathan.

1 0

Release of logback version 1.0.3
by ceki 07 May '12

07 May '12

Hello all, I am happy to announce the release of logback version 1.0.3. It should hit the Maven central repository within the next 24 hours. Please refer to the news page for precise details of this release. http://logback.qos.ch/news.html You can download logback, 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 QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki http://twitter.com/#!/ceki

2 3

Inverse log4j-over-slf4j?
by Mike Boyers 07 May '12

07 May '12

We have a project that uses slf4j/logback for its logging. We have dependencies we're pulling in that are using log4j, so for that, we're using the log4j-over-slf4j bridge. We have a single logback.xml configuration that controls it all, and everything is fine. But we publish artifacts, and other projects have our artifacts as their dependencies, and they are using log4j strictly. Let's assume they know nothing about logback and have no desire to switch. What technique to people typically follow in this case? Is there an inverse log4j-over-slf4j bridge? Thanks, Mike

3 3

Re: [logback-user] Setting log LEVEL on a per <appender-ref/> basis
by Shane Kelly 06 May '12

06 May '12

Hi Ceki, Thanks for your prompt response. I wasn't aware of routing appenders - so this is something that I shall certainly look into. My main motivation for wanting to do this was primarily so that I could control the verboseness of logging for the same logger depending on the destination appender without having to create several (almost duplicate) appender configurations (whilst setting slightly different threshold levels for each) - as far as possible I only wanted to create a single appender configuration entry for each distinct destination - i.e. Console, RollingFile etc. So, for example, I might have a logger in a Java class which generates log messages of varying levels, but I only want INFO and above to go to a Console appender, whilst I want DEBUG and above to be written to a RollingFileAppender - for the same class - simply because I don't want to clog up STDOUT with too much information (unless I need to) but have a separate file to fall back to which does contain a complete set of log messages for reference/debug at a later date. Is there any documentation describing how to create routing appenders (I had a quick look and couldn't see anything) or is there an example of such an appender lurking somewhere within the source that you could point me towards? Regards, Shane > Hello Shane, > > There are probably multiple approaches to this problem. It should be not > too difficult to write a RoutingAppender which can perform the type of > routing operation you describe. Here is how the config file would look like: > > <appender name="A"></appender> > <appender name="B"></appender> > > <appender name="ROUTING-ONE" class="...RoutingAppender"> > <reference name="A" level="INFO"/> > <reference name="B" level="DEBUG"/> > </appender> > > <appender name="ROUTING-TWO" class="...RoutingAppender"> > <reference name="A" level="WARN"/> > <reference name="B" level="TRACE"/> > </appender> > > <logger name="com.myorg.myapp.**subpackage.one"> > <appender-ref ref="ROUTING-ONE"/> > </logger> > > <logger name="com.myorg.myapp.**subpackage.two"> > <appender-ref ref="ROUTING-TWO"/> > </logger> > > > By the way, could you provide more detail for your use case? > > Cheers, > -- > Ceki > http://twitter.com/#!/ceki > > > On 05.05.2012 22:48, Shane Kelly wrote: > >> Folks, >> >> I've been tinkering with both log4j and more recently logback and I was >> wondering whether or not it is possible to configure it in such a way >> that it would be possible for a single logger to write to multiple >> appenders using different LEVEL restrictions on a per-appender-ref >> basis. I appreciate that it is possible to specify a LEVEL attribute for >> each individual logger - but then any message which meets the logger >> LEVEL criteria will be sent to all referenced appenders. I'm also aware >> that you can define level thresholds and filters on a per-appender basis >> - but what I was hoping for was rather than define lots of very similar >> appender configurations (each with slightly different thresholds) that I >> could define a smaller number of core appenders and have messages of >> certain levels filtered out even before the appender is called. >> >> To help illustrate the concept I'm aiming for, I've included a >> pseudo-configuration file below. You'll notice that I've omitted the >> LEVEL attribute from the <logger/> nodes and added LEVEL attributes to >> each of the <appender-ref> nodes - this doesn't work obviously, but I >> was wondering if there was some other way of emulating the behaviour >> that I'm after without cluttering up the logback configuration too >> much...? You can see from the configuration that for >> com.myorg.myapp.subpackage.one I would like to apply different log level >> restrictions depending on the destination appender. You'll also notice >> that for com.myorg.myapp.subpackage.two I want to reuse the same >> appenders, but also use different level restrictions.... hope that makes >> it clear enough... >> >> --------- >> >> <appender name="A"> >> ... >> ... >> </appender> >> >> <appender name="B"> >> ... >> ... >> </appender> >> >> <logger name="com.myorg.myapp.**subpackage.one"> >> <appender-ref ref="A" LEVEL="INFO"/> >> <appender-ref ref="B" LEVEL="DEBUG"/> >> </logger> >> >> <logger name="com.myorg.myapp.**subpackage.two"> >> <appender-ref ref="A" LEVEL="WARN"/> >> <appender-ref ref="B" LEVEL="TRACE"/> >> </logger> >> >> ---------- >> >> Regards, >> >> Shane >> >> > ______________________________**_________________ > Logback-user mailing list > Logback-user(a)qos.ch > http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user> > >

2 2