June 2017 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1320) Logback not capturing all log messages from JUL
by QOS.CH (JIRA) 28 Jun '17

28 Jun '17

Nathan Lighthart created LOGBACK-1320: ----------------------------------------- Summary: Logback not capturing all log messages from JUL Key: LOGBACK-1320 URL: https://jira.qos.ch/browse/LOGBACK-1320 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.2.3, 0.9.25 Reporter: Nathan Lighthart Assignee: Logback dev list Priority: Minor Attachments: JULHelper.java, logback.xml, Main.java INFO and CONFIG messages in JUL are classified as INFO messages in Logback. FINE and FINER messages in JUL are classified as DEBUG messages in Logback. When using the LevelChangePropagator, it is expected when the Logback level is INFO that both INFO and CONFIG messages in JUL are captured. The same should be true about FINE and FINER messages when the Logback level is DEBUG. However, when the Logback level is INFO, CONFIG messages are not captured; while, INFO messages are. When the Logback level is DEBUG, FINER messages are not captured; while, FINE messages are. How to Reproduce: I have attached my logback configuration file as well as a simple main class which logs INFO, CONFIG, FINE, FINER, and FINEST messages. Solutions: It appears the problem stems from JULHelper.asJULLevel() method. When the level is DEBUG, FINE is returned. When the level is INFO, then INFO is returned. This method should return FINER for DEBUG and CONFIG for INFO. I have attached a modified version of the JULHelper. As JULHelper.asJULLevel() is part of the public API this change may impact users that directly call this method. Therefore if you want to preserve backwards compatibility, you can add another method like asLowerJULLevel() which returns FINER and CONFIG in the appropriate place. Then in the LevelChangePropagator call asLowerJULLevel() in the propagate() method. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1319) framework packages are not excluded properly
by QOS.CH (JIRA) 24 Jun '17

24 Jun '17

Bug Reporter created LOGBACK-1319: ------------------------------------- Summary: framework packages are not excluded properly Key: LOGBACK-1319 URL: https://jira.qos.ch/browse/LOGBACK-1319 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.2.3 Reporter: Bug Reporter Assignee: Logback dev list The [LoggerContext.getFrameworkPackages|https://logback.qos.ch/apidocs/ch/qos/logback/classic/LoggerContext.html#getFrameworkPackages()] documentation says this is a list of packages (including their subpackages) that get excluded when tracing the caller. But the implementation in [CallerData.isInFrameworkSpaceList|https://github.com/qos-ch/logback/blob/ma…] is wrong because "com.foo" matches "com.foobar" which is not its subpackage. I suggest changing {code:java} if (currentClass.startsWith(s)){code} to {code:java} if (currentClass.startsWith(s + ".")){code} or even {code:java} if (currentClass.equals(s) || currentClass.startsWith(s + ".")){code} in case someone relies on this behavior to exclude specific classes (which would be nice anyway). We could also add {code:java} if (s.equals("")) return !currentClass.contains("."){code} to support excluding the default package classes. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1318) LoggingEvent.prepareForDeferredProcessing doesn't need to call LoggingEvent.getFormattedMessage
by QOS.CH (JIRA) 23 Jun '17

23 Jun '17

William Li created LOGBACK-1318: ----------------------------------- Summary: LoggingEvent.prepareForDeferredProcessing doesn't need to call LoggingEvent.getFormattedMessage Key: LOGBACK-1318 URL: https://jira.qos.ch/browse/LOGBACK-1318 Project: logback Issue Type: Improvement Components: logback-classic Reporter: William Li Assignee: Logback dev list Priority: Minor LoggingEvent.prepareForDeferredProcessing should be called when using asynchronous or deferred logging. The code is as blow. The first line may cause log event serialization, which is time-cosuming when the message is big. Actually, it is not need to have this line of code. The code was added in [https://github.com/qos-ch/logback/commit/dfd340815e36f475cd014fd85915dbbafa….] by Ceki Gulcu in 2010. The comment is "all logback-classic and logback-core tests pass". Actually, no test case failure if this line is removed. I would suggest to remove this line, so that the log event will not be serialized untile the logger thread really need the formatted message. {quote}public void prepareForDeferredProcessing() \{ _*this.getFormattedMessage();*_ this.getThreadName(); // fixes http://jira.qos.ch/browse/LBCLASSIC-104 this.getMDCPropertyMap(); }{quote} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1317) Change the scope of the servlet-api from compile/optional to provided
by QOS.CH (JIRA) 23 Jun '17

23 Jun '17

1 0

[JIRA] (LOGBACK-1317) Change the scope of the servlet-api from compile/optional to provided
by QOS.CH (JIRA) 23 Jun '17

23 Jun '17

Emmanuel Bourg created LOGBACK-1317: --------------------------------------- Summary: Change the scope of the servlet-api from compile/optional to provided Key: LOGBACK-1317 URL: https://jira.qos.ch/browse/LOGBACK-1317 Project: logback Issue Type: Improvement Components: logback-classic Affects Versions: 1.2.3 Reporter: Emmanuel Bourg Assignee: Logback dev list Priority: Trivial The dependency for the Servlet API has the {{compile}} scope and is marked as optional. Usually in this situation the {{provided}} scope should be used because it's supposed to be provided by the servlet container. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1316) Docs for reqParameter describe it as "Parameter of the response"
by QOS.CH (JIRA) 22 Jun '17

22 Jun '17

Robert Kuhar created LOGBACK-1316: ------------------------------------- Summary: Docs for reqParameter describe it as "Parameter of the response" Key: LOGBACK-1316 URL: https://jira.qos.ch/browse/LOGBACK-1316 Project: logback Issue Type: Bug Components: logback-access Environment: Reporter: Robert Kuhar Assignee: Logback dev list Priority: Minor I'm looking at [https://logback.qos.ch/manual/layouts.html#AccessPatternLayout] and see that there is a parameter who's "Conversion Word" is reqParameter but who's "Effect" is described as "Parameter of the response". Later in the "Effect" its says "...looks for the corresponding parameter in the request.". That first sentence of the Effect should be "Parameter of the request.", no? -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1248) Allow leading zeros in %i pattern
by QOS.CH (JIRA) 20 Jun '17

20 Jun '17

1 0

[JIRA] (LOGBACK-339) thrown from toString exception swallowed
by QOS.CH (JIRA) 19 Jun '17

19 Jun '17

1 0

[JIRA] (LOGBACK-1314) NumberFormatException: For input string: "-"
by QOS.CH (JIRA) 19 Jun '17

19 Jun '17

1 0

JDK 9 EA Build 174 & JDK 8u152 b04 are available on jdk.java.net
by Rory O'Donnell 16 Jun '17

16 Jun '17

Hi Ceki, *JDK 9 Early Access* build 174 is available at : - jdk.java.net/9/ A summary of all the changes in this build are listed here <http://download.java.net/java/jdk9/changes/jdk-9+174.html>. Changes which were introduced since the last availability email that may be of interest : * b172 - JDK-8179014 : JFileChooser with Windows look and feel crashes on win 10 * b173 - JDK-8180582 : the bind to rmiregistry is rejected by registryFilter even though registryFilter is set * b174 - JDK-8181702 : deprecate for removal the following tool modules:jdk.xml.bind and jdk.xml.ws *JDK 9 Schedule Update* * The new GA date for JDK 9 is now set to 2017-09-21 [1] * We have updated the OpenJDK JDK 9 project page [2] with the new milestones and GA date. *JDK 8u152 Early Access* build 04 is available at : - jdk.java.net/8/ <http://jdk.java.net/8/> A summary of all the changes in this build are listed here <http://download.java.net/java/jdk8u152/changes/jdk8u152-b04.html>. Information and schedules specific to OpenJDK 8u152 release [3] Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-June/005867.html [2] http://openjdk.java.net/projects/jdk9/ [3] http://openjdk.java.net/projects/jdk8u/releases/8u152.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0