- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1333) Snapshot version typo: SNAPSHPOT
by QOS.CH (JIRA) 27 Sep '17

27 Sep '17

Jan Engehausen created LOGBACK-1333: --------------------------------------- Summary: Snapshot version typo: SNAPSHPOT Key: LOGBACK-1333 URL: https://jira.qos.ch/browse/LOGBACK-1333 Project: logback Issue Type: Bug Components: logback-core Environment: Hello, the current master has several {{pom.xml}} files with {{1.3.0-SNAPSHPOT}} - that of course should be {{1.3.0-SNAPSHOT}} ;) Reporter: Jan Engehausen Assignee: Logback dev list Priority: Trivial -- This message was sent by Atlassian JIRA (v7.3.1#73012)

2 1

[JIRA] (LOGBACK-1333) Snapshot version typo: SNAPSHPOT
by QOS.CH (JIRA) 27 Sep '17

27 Sep '17

1 0

[JIRA] (LOGBACK-1343) Make logback Java 9 friendly by removing use of sun.reflect.Reflection
by QOS.CH (JIRA) 22 Sep '17

22 Sep '17

Michael created LOGBACK-1343: -------------------------------- Summary: Make logback Java 9 friendly by removing use of sun.reflect.Reflection Key: LOGBACK-1343 URL: https://jira.qos.ch/browse/LOGBACK-1343 Project: logback Issue Type: Bug Reporter: Michael Assignee: Logback dev list Priority: Minor jdeps is reporting logback uses sun.reflect.Reflection, it recommends using StackWalker ch.qos.logback.classic.spi.PackagingDataCalculator -> sun.reflect.Reflection JDK internal API (jdk.unsupported) JDK Internal API Suggested Replacement ---------------- --------------------- sun.reflect.Reflection Use java.lang.StackWalker @since 9 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Release Announcement: General Availability of JDK 9
by Rory O'Donnell 21 Sep '17

21 Sep '17

Hi Ceki, Three items to share with you today * *JDK 9 General Availability * o GPL'd binaries from Oracle are available here: + http://jdk.java.net/9 o See Mark Reinhold's email for more details on the Release [1] + delivery of Project Jigsaw [2] * Are you JDK 9 Ready ? o The Quality Outreach wiki has been updated to include a JDK 9 Ready column. o If you would like us to identify your project as JDK 9 ready , please let me know and I will add it to the wiki. * Quality Outreach Report for September 2017**is available o many thanks for your continued support and welcome to the new projects! Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html [2] https://mreinhold.org/blog/jigsaw-complete -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

Reason of taking timeStamp in the end of LoggingEvent constructor?
by Truuba 21 Sep '17

21 Sep '17

Hi I was wondering, and actually have been a bit confused, that the *timeStamp *of a logging event is taken in the end of the *LoggingEvent *constructor. Just without further thinking, I would place this to the beginning of the constructor to be as near as possible to the actual event. Now thinking a bit further, placing the *timeStamp *to the beginning seems only getting more reasonable. The constructor contains logic, which depends on the given parameters. This logic will take some time, depending if the current event has a *throwable *or not. This time will be implicitly added as offset to the original event. If I create two logs within a very close time (few ms), one containing a *throwable *and one without, it might even happen, that the original order isn't guaranteed anymore, as, due the offset of the constructor running time, the first event finally might have a later time stamp than the second. So what is the design reason of taking the *timeStamp *in the end? I don't see a single benefit. Of course I still might have understood something wrong. regards marco

1 0

[JIRA] (LOGBACK-1342) java.lang.NoClassDefFoundError: ch/qos/logback/core/util/StatusListenerConfigHelper
by QOS.CH (JIRA) 19 Sep '17

19 Sep '17

1 0

[JIRA] (LOGBACK-1342) java.lang.NoClassDefFoundError: ch/qos/logback/core/util/StatusListenerConfigHelper
by QOS.CH (JIRA) 19 Sep '17

19 Sep '17

Ifeanyi Agu created LOGBACK-1342: ------------------------------------ Summary: java.lang.NoClassDefFoundError: ch/qos/logback/core/util/StatusListenerConfigHelper Key: LOGBACK-1342 URL: https://jira.qos.ch/browse/LOGBACK-1342 Project: logback Issue Type: Bug Components: logback-classic, logback-core Affects Versions: 1.2.3 Reporter: Ifeanyi Agu Assignee: Logback dev list I updated logback to 1.2.3 and slf4j to 1.7.25 but i get this error when I run unit tests that have {code:java} private static Logger logger = LoggerFactory.getLogger(RemoteAddressUtil.class);{code} my tests fail with {code:java} Reported exception: java.lang.NoClassDefFoundError: ch/qos/logback/core/util/StatusListenerConfigHelper at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:147) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383) {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1161) NoClassDefFoundError
by QOS.CH (JIRA) 19 Sep '17

19 Sep '17

1 0

[JIRA] (LOGBACK-1341) SizeAndTimeBasedRollingPolicy does not zip all the files on day change
by QOS.CH (JIRA) 14 Sep '17

14 Sep '17

Abhishek Mundewal created LOGBACK-1341: ------------------------------------------ Summary: SizeAndTimeBasedRollingPolicy does not zip all the files on day change Key: LOGBACK-1341 URL: https://jira.qos.ch/browse/LOGBACK-1341 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: Reporter: Abhishek Mundewal Assignee: Logback dev list SizeAndTimeBasedRollingPolicy does not zip all the files on day change. Due to that it does not clean/delete the older (older than MaxHistory) files. We've the application those are generating big (2GB/3GB) log files on daily basis, so that's why we moved to SizeAndTimeBasedRollingPolicy from TimeBasedRollingPolicy, but here is a problem that (SizeAndTimeBasedRollingPolicy) does not zip/archive all the files on day change, that's why when max history reached the files which were archived/zipped were deleted but rest were left there. I googled but did not find any solution for that. Please consider adding this feature to Logback and feel free to contact me if further clarification is required. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1340) Color support and OSGi
by QOS.CH (JIRA) 13 Sep '17

13 Sep '17

Antonio Facciorusso created LOGBACK-1340: -------------------------------------------- Summary: Color support and OSGi Key: LOGBACK-1340 URL: https://jira.qos.ch/browse/LOGBACK-1340 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.2.3 Environment: Equinox OSGi environment running on Windows 10 Pro 64bit. Logback: 1.2.3 Jansi: 1.16 Reporter: Antonio Facciorusso Assignee: Logback dev list Attachments: logback-classic-jansi-error.log The following exception is thrown when _"<withJansi>true</withJansi>"_ is used with ConsoleAppender on Windows (full stack trace in attached log file): _16:39:40,801 |-WARN in ch.qos.logback.core.ConsoleAppender[STDOUT] - Failed to create WindowsAnsiOutputStream. Falling back on the default stream. ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type org.fusesource.jansi.WindowsAnsiOutputStream_ _at ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type org.fusesource.jansi.WindowsAnsiOutputStream_ _at at ch.qos.logback.core.util.OptionHelper.instantiateByClassNameAndParameter(OptionHelper.java:69)_ ... _Caused by: java.lang.ClassNotFoundException: org.fusesource.jansi.WindowsAnsiOutputStream cannot be found by ch.qos.logback.classic_1.2.3_ _at at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432)_ _at at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345)_ _at at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337)_ _at at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)_ _at at java.lang.ClassLoader.loadClass(ClassLoader.java:357)_ _at at ch.qos.logback.core.util.OptionHelper.instantiateByClassNameAndParameter(OptionHelper.java:56)_ _at ... 49 common frames omitted_ the jansi library correctly exports this package and logback-core correctly imports the same package. It seems that the following entry is missing in logback-classic's MANIFEST.MF file: *org.fusesource.jansi; resolution:=optional; version="[1.9, 2)"* -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0