- logback-user - mailman3.qos.ch

OSGi wiring problems when using SLF4J+Logback
by Joel W 01 Feb '16

01 Feb '16

Hi all, I’m switching logging mechanisms from JUL to SLF4J+Logback on an application that is an OSGi bundle - it’s a plugin for an OSGi application. However, I’m getting some wiring problems: many Logback dependencies don’t seem to be resolved. I have the relevant Maven dependencies as follows: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.12</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.1.3</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.1.3</version> </dependency> All 3 of these are specified in the class path of the application runner script. This script also points to a basic logback.xml configuration file that just prints to stdout. For bundling I use the maven-bundle-plugin v3.0.1, where the relevant directives are: <Export-Package> org.slf4j*, ch.qos.logback* </Export-Package> <Embed-Transitive>true</Embed-Transitive> The application gets assembled using maven-assembly-plugin v2.6; I’ve attempted to have the above 3 dependencies start as bundles, before the main application, or simply included them in my /lib/ folder. Upon attempting to initialize the application, I get the error: 14:13:01.540 [FelixStartLevel] ERROR o.p.o.framework.FrameworkSlf4jLogger - Error starting file:/…/app-name/target/distribution/bundles/app.jar org.osgi.framework.BundleException: Unresolved constraint in bundle app [15]: Unable to resolve 15.0: missing requirement [15.0] osgi.wiring.package; (osgi.wiring.package=groovy.lang) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4002) ~[org.apache.felix.main-4.4.1.jar:na] at org.apache.felix.framework.Felix.startBundle(Felix.java:2045) ~[org.apache.felix.main-4.4.1.jar:na] at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1299) ~[org.apache.felix.main-4.4.1.jar:na] at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304) [org.apache.felix.main-4.4.1.jar:na] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25] If I include groovy.lang* in the <Export-Package> directive, then I get another missing requirement: javax.jms, and this keeps going with packages that Logback depends on (javax.mail, java.mail.internet, javax.servlet…). I’ve experimented quite a bit, but unfortunately I can’t spot what I’m missing or doing wrong. Does anyone have any idea what might be wrong? Any help would be greatly appreciated! Many thanks, Joel

2 2

RollingFileAppender behaving weird
by Brecht Yperman 01 Feb '16

01 Feb '16

Hi everyone, We recently had an issue on one of our production servers. We never had this problem before, so unfortunately it's not something I can reproduce. The symptom was that the server continuously used 1 CPU. We took some thread dumps and saw one thread was rolling the files. "Server Thread: /81.82.251.166:53103" - Thread t@35951 java.lang.Thread.State: RUNNABLE at java.util.zip.Deflater.deflateBytes(Native Method) at java.util.zip.Deflater.deflate(Deflater.java:442) - locked <29369617> (a java.util.zip.ZStreamRef) at java.util.zip.Deflater.deflate(Deflater.java:364) at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:251) at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:211) at java.util.zip.ZipOutputStream.write(ZipOutputStream.java:331) - locked <528548da> (a java.util.zip.ZipOutputStream) at ch.qos.logback.core.rolling.helper.Compressor.zipCompress(Compressor.java:110) at ch.qos.logback.core.rolling.helper.Compressor.compress(Compressor.java:58) at ch.qos.logback.core.rolling.FixedWindowRollingPolicy.rollover(FixedWindowRollingPolicy.java:157) at ch.qos.logback.core.rolling.RollingFileAppender.attemptRollover(RollingFileAppender.java:158) at ch.qos.logback.core.rolling.RollingFileAppender.rollover(RollingFileAppender.java:137) at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:178) - locked <38d457ec> (a ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:103) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:273) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:260) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:442) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:433) at ch.qos.logback.classic.Logger.debug(Logger.java:511) ... A thread dump from a few minutes later showed a different thread with more or less the exact same stack trace. The appender looks like this: <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>E:\Invenso\Logging\xbiadmin.log.txt</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>E:\Invenso\Logging\xbiadmin.%i.log.zip</fileNamePattern> <minIndex>1</minIndex> <maxIndex>5</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>25MB</maxFileSize> </triggeringPolicy> <encoder> <pattern>%d{"dd-MM-yy HH:mm:ss,SSS"} - [%t] %-5p - %m%n</pattern> </encoder> </appender> (Unfortunately, this configuration is recreated on restart, and we did not think to copy the configuration. It is possible that this configuration looked somewhat different when the issue occurred) When we took a look at the log files, we immediately saw all log files being equal in size. If we took a look inside the zip files, we saw all files being equal, and the same as the actual log files. So we had 6 files: - 5 zip files (16,076 KB) - 1 txt file (32,554 KB) The log file is bigger than the maxFileSize configured and the contents of the six files are identical. I noticed that one of the lines logged was over 6Mb, and if I remove this line and all the subsequent lines, the file is 24,906 KB. Any help on what went wrong here, or what we can do to better investigate this should this occur another time would be much appreciated. Thanks, Brecht

1 0

Version 1.1.4 Release Date?
by Sheldon Warkentin 28 Jan '16

28 Jan '16

Hi there, The version of logback-classic and logback-core my team is using was recently bumped to a newer version (1.1.2) due to other dependencies (dropwizard-logging). This introduced the bug, http://jira.qos.ch/browse/LOGBACK-910 to our source. I see the problem was resolved march 2015 in the changeset https://github.com/qos-ch/logback/commit/df0e5f936755cc866ff65, targeting verison 1.1.4. Is there any word on when version 1.1.4 will be released? Thanks, Sheldon

1 0

logback-access configuration
by Roman Babenko 25 Jan '16

25 Jan '16

1 0

Why is modification time of log file important?
by Hee Min Kim 11 Jan '16

11 Jan '16

Hi everyone, I have a question about the meaning of checking modification time of log file before deleting it. I configured hourly based log appender. Some times, there are no logs appended for more than an hour. In this case, the gap between time in an archived file name and the file's modification time is more than an hour. Which means the file will remain forever until user delete it manually. Is it intended behavior? Why should it check modification time of log file before deleting it? Thanks

1 0

Separate stacktrace from others logs
by Matthieu Nantern 29 Dec '15

29 Dec '15

Hello ! I'd like to separate my stacktrace from other logs in 2 different files. I manage to do that with 2 appenders: The first one with %nopex: <encoder> <charset>UTF-8</charset> <pattern>%nopex %d{dd/MM/yyyy-HH:mm:ss.SSS} [%thread][%X{TRANSACTION_ID}] %-5level %logger{36}:%L - %msg%n</pattern> </encoder> The second with only %xException{full} But now I want to add my MDC field TRANSACTION_ID when an exception arises (and only when an exception pop up). Just adding %X{TRANSACTION_ID} to my pattern doesn't work, I have a new line for every log line even when I don't have any exception. Do you have any idea of how to do it ? Thank you !

1 0

Customizing log level display in with logback and logstash-logback encoder
by Debraj Manna 27 Dec '15

27 Dec '15

I am using logstash-logback-encoder to print logs in json format. My logback.xml looks like below:- <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="net.logstash.logback.encoder.LogstashEncoder"> <includeContext>false</includeContext> <fieldNames> <timestamp>timestamp</timestamp> <version>[ignore]</version> <levelValue>[ignore]</levelValue> </fieldNames> </encoder> </appender> <appender name="stash" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/tmp/SolrUpdater.%d{yyyy-MM-dd}.log </fileNamePattern> <maxHistory>7</maxHistory> </rollingPolicy> <encoder class="net.logstash.logback.encoder.LogstashEncoder"> <includeContext>false</includeContext> <fieldNames> <timestamp>timestamp</timestamp> <version>[ignore]</version> <levelValue>[ignore]</levelValue> </fieldNames> </encoder> </appender> <root level="error"> <appender-ref ref="CONSOLE" /> <appender-ref ref="stash" /> </root> </configuration> Can someone let me know how can I display all level in lowercase like error, rather than the default ERROR and WARN as warning? Thanks, Debraj

1 1

Groovy configuration includes
by Charlie Pai 18 Dec '15

18 Dec '15

Hi, Is there any way for groovy configuration to do something like <include file="logback-parent.xml" /> with current logback functionality? I noticed that http://jira.qos.ch/browse/LOGBACK-1002 says that there isn't something like that at the moment, and the pull request for it is still open (https://github.com/qos-ch/logback/pull/257) We need to have different runtime configurations of logback depending on the environment, especially for production. If logback.groovy is inside the jar then any potential issues with logback that might arise in production can't be fixed quickly without messing with the jar, so this issue is blocking us from migrating to groovy away from xml. Thanks, CP

2 2

Escape % in FileNamePattern
by mota 16 Dec '15

16 Dec '15

Hi, I'd like to know how to escape % special character in fileNamePattern of TimeBasedRollingPolicy. The path contains % character, but escape backslash in fileNamePattern is interpreted as directory separator. Thanks, Tomas

1 0

Simple web application (LogUI) to manage runtime logback configuration online.
by Stanislav Spiridonov 09 Dec '15

09 Dec '15

Hi, I am an author of simple JEE application to manage runtime logback configuration online. The first version is only allows to show current logger list and manage log levels. Main goal was to simplify the integration with "customer" projects. So it is enough to add only one maven dependency to start using the LogUI in modern JEE application. LogUI is a web fragment and will appear on /jrs/logui/index.html after that. You can test the demo application in action on http://dev.chnch.us/loguidemo Source code and other information is on Bitbucket: https://bitbucket.org/foal/open-logui Will be very glad if you will put a reference to the protect on logback site (http://logback.qos.ch/download.html) Best, Stanislav

1 0