March 2017 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-397) Bridge can still call underlying logging system with a null message.
by QOS.CH (JIRA) 07 Mar '17

07 Mar '17

Joern Huxhorn created SLF4J-397: ----------------------------------- Summary: Bridge can still call underlying logging system with a null message. Key: SLF4J-397 URL: https://jira.qos.ch/browse/SLF4J-397 Project: SLF4J Issue Type: Bug Components: jul-to-slf4j Affects Versions: 1.7.24 Environment: any Reporter: Joern Huxhorn Assignee: SLF4J developers list I just found a bug while preparing SLF4J-396. {code:java} private String getMessageI18N(LogRecord record) { String message = record.getMessage(); if (message == null) { return null; } // [..] } {code} should be changed to {code:java} private String getMessageI18N(LogRecord record) { String message = record.getMessage(); // can be null! // this is a check to avoid calling the underlying logging system // with a null message. While it is legitimate to invoke j.u.l. with // a null message, other logging frameworks do not support this. // see also http://jira.qos.ch/browse/SLF4J-99 if (message == null) { return ""; } // [..] } {code} and {code:java} public void publish(LogRecord record) { // Silently ignore null records. if (record == null) { return; } Logger slf4jLogger = getSLF4JLogger(record); String message = record.getMessage(); // can be null! // this is a check to avoid calling the underlying logging system // with a null message. While it is legitimate to invoke j.u.l. with // a null message, other logging frameworks do not support this. // see also http://jira.qos.ch/browse/SLF4J-99 if (message == null) { message = ""; } if (slf4jLogger instanceof LocationAwareLogger) { callLocationAwareLogger((LocationAwareLogger) slf4jLogger, record); } else { callPlainSLF4JLogger(slf4jLogger, record); } } {code} should be changed to {code:java} public void publish(LogRecord record) { // Silently ignore null records. if (record == null) { return; } Logger slf4jLogger = getSLF4JLogger(record); if (slf4jLogger instanceof LocationAwareLogger) { callLocationAwareLogger((LocationAwareLogger) slf4jLogger, record); } else { callPlainSLF4JLogger(slf4jLogger, record); } } {code} The local {{message}} variable was assigned but never used. I suspect some refactoring sneakily reintroduced the problematic case where the underlying logging system is called with a {{null}} message. {{getMessageI18N}} is called by both {{callLocationAwareLogger}} and {{callPlainSLF4JLogger}} so this fix should be fine. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-396) Support jul sourceClassName and sourceMethodName in slf4j-bridge.
by QOS.CH (JIRA) 07 Mar '17

07 Mar '17

Joern Huxhorn created SLF4J-396: ----------------------------------- Summary: Support jul sourceClassName and sourceMethodName in slf4j-bridge. Key: SLF4J-396 URL: https://jira.qos.ch/browse/SLF4J-396 Project: SLF4J Issue Type: Improvement Components: jul-to-slf4j Affects Versions: 1.7.24 Environment: any Reporter: Joern Huxhorn Assignee: SLF4J developers list The {{SLF4JBridgeHandler}} is currently dropping some log record info while bridging to slf4j. The reason for this is that {{java.util.logging}} logger names are different beasts than slf4j ones. While it is a very common convention that an slf4j logger name equals the class name it's responsible for, this isn't necessarily the case for {{java.util.logging}}. That's why {{LogRecord}} contains {{sourceClassName}} and {{sourceMethodName}} fields that are populated by {{Logger.entering}}, {{Logger.exiting}}, {{Logger.throwing}} and the general {{logp/logrb}} methods. That info is crucial to the point where the log records are relatively useless without it. Example: {{Logger.entering("SourceClass","sourceMethod")}} will result in an event that simply says {{ENTRY}}. Furthermore, {{jul}} allows for custom {{Level}} instances with a name and an arbitrary {{intValue()}}. While losing those is way less critical since they are already mapped to slf4j levels in a reasonable way, I think it would still be worthwhile to keep that info around. I'd suggest to add the following to {{SLF4JBridgeHandler}}: {code:java} private static final String LEVEL_MDC_KEY = "JUL-Level"; private static final String LEVEL_VALUE_MDC_KEY = "JUL-Level-Value"; private static final String SOURCE_CLASS_NAME_MDC_KEY = "JUL-SourceClassName"; private static final String SOURCE_METHOD_NAME_MDC_KEY = "JUL-SourceMethodName"; private static void initMDC(LogRecord record) { Level julLevel = record.getLevel(); MDC.put(LEVEL_MDC_KEY, julLevel.getName()); MDC.put(LEVEL_VALUE_MDC_KEY, Integer.toString(julLevel.intValue())); String sourceClassName = record.getSourceClassName(); if(sourceClassName != null) { MDC.put(SOURCE_CLASS_NAME_MDC_KEY, sourceClassName); } String sourceMethodName = record.getSourceMethodName(); if(sourceMethodName != null) { MDC.put(SOURCE_METHOD_NAME_MDC_KEY, sourceMethodName); } } private static void clearMDC() { MDC.remove(LEVEL_MDC_KEY); MDC.remove(LEVEL_VALUE_MDC_KEY); MDC.remove(SOURCE_CLASS_NAME_MDC_KEY); MDC.remove(SOURCE_METHOD_NAME_MDC_KEY); } {code} Those methods would then be used in {{publish(LogRecord record)}}: {code:java} initMDC(record); try { if (slf4jLogger instanceof LocationAwareLogger) { callLocationAwareLogger((LocationAwareLogger) slf4jLogger, record); } else { callPlainSLF4JLogger(slf4jLogger, record); } } finally { clearMDC(); } {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-394) add renderThrowable() and renderLevel() protected methods + mark LOG_LEVEL_* protected in simple provider
by QOS.CH (JIRA) 04 Mar '17

04 Mar '17

[ https://jira.qos.ch/browse/SLF4J-394?page=com.atlassian.jira.plugin.system.… ] Hervé Boutemy commented on SLF4J-394: ------------------------------------- sorry, I still can't close the issue > add renderThrowable() and renderLevel() protected methods + mark LOG_LEVEL_* protected in simple provider > --------------------------------------------------------------------------------------------------------- > > Key: SLF4J-394 > URL: https://jira.qos.ch/browse/SLF4J-394 > Project: SLF4J > Issue Type: Improvement > Components: slf4j-simple > Affects Versions: 1.7.24 > Environment: Apache Maven 3.5 with maven-slf4j-provider http://maven.apache.org/ref/3-LATEST/maven-slf4j-provider/ > Reporter: Hervé Boutemy > Assignee: Ceki Gülcü > Fix For: 1.7.25 > > > Apache Maven created a Groovy monkey patch to extract such renderThrowable() and renderLevel() and being able to override these methods in a local provider, which is essentially slf4j-simple with a little rendering improvement > see [https://git-wip-us.apache.org/repos/asf/maven/?p=maven.git;a=blob;f=maven-s…] > Having these changes directly in slf4j simple provider should not change much things, and would avoid us the Groovy patch dependency: the provider will still be required, since we can't have 2 providers in the classpath, and adding real extension/configuration to slf4j simple is much more complex -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 9 EA Build 159 and JDK 8u152 is available on java.net
by Rory O'Donnell 03 Mar '17

03 Mar '17

Hi Ceki, *JDK 8u152 **Early Access b01 <https://jdk8.java.net/download.html> *is available on java.net *JDK 9 Early Access* b159 <https://jdk9.java.net/download/> is available on java.net, summary of changes are listed here <http://download.java.net/java/jdk9/changes/jdk-9+159.html>. There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * b159 - JDK-8175261 : Per-protocol cache setting not working for JAR URLConnection * b158 - JDK-8173028 : Incorrect processing of supplementary-plane characters in text fields * b158 - JDK-8172967 : [macosx] Exception while working with layout for text containing unmappable character * b158 - JDK-8173804 : javadoc throws UnsupportedOperationException: should not happen * b157 - JDK-8174073 : NPE caused by @link reference to class * b156 - JDK-8172726 : ForkJoin common pool retains a reference to the thread context class loader The following changeset is included in jdk-9+158: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8b0d55e02f54 If you have a user-defined Policy implementation that grants FilePermission on ${user.dir}/-, reading a file in the current directory using its base name will fail. Still the same solution: Ensure that the path used in permission granting has the same style as the one how you access the file. Setting -Djdk.security.filePermCompat=true will take you back to the jdk-9+140 behavior. Setting -Djdk.io.permissionsUseCanonicalPath=true will take you back to the jdk8 behavior. Feedback is welcome on jdk9-dev(a)openjdk.java.net Other areas of interest * JDK 9 Developer Guide [1] * JDK 9 Migration Guide [2] * JDK Cryptographic Roadmap [3] Finaly, Dalibor and I gave a presentation at FOSDEM the video is available here [*4*] Rgds,Rory [1] http://docs.oracle.com/javase/9/javase-docs.htm [2] https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4… [3] https://www.java.com/en/jre-jdk-cryptoroadmap.html [4] https://fosdem.org/2017/schedule/event/outreach/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0