September 2017 - logback-dev

[JIRA] (LOGBACK-1313) RollingFileAppender / SizeBasedTriggeringPolicy : filename with character "-' is not rolled over
by QOS.CH (JIRA) 28 Sep '17

28 Sep '17

1 0

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

28 Sep '17

1 0

[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