May 2018 - slf4j-dev - mailman3.qos.ch

JDK 11 Early Access build 15 is available for download.
by Rory O'Donnell 29 May '18

29 May '18

Hi Ceki, **JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. ** * * Newly approved Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o http://jdk.java.net/11/changes *Notable changes in JDK 11 EA builds since last email:* * b15 - JDK-8201627 <http://bugs.openjdk.java.net/browse/JDK-8201627> - Kerberos sequence number issues * b13 - JDK-8200146 <http://bugs.openjdk.java.net/browse/JDK-8200146> - Removal of appletviewer launcher o deprecated in JDK 9 and has been removed in this release * b13 - JDK-8201793 <http://bugs.openjdk.java.net/browse/JDK-8201793> - java.lang.ref.Reference does not support cloning ** ** JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC) 330: Launch Single-File Source-Code Programs <http://openjdk.java.net/jeps/330> JEPs targeted to JDK 11, so far 309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309> 318: Epsilon: A No-Op Garbage Collector <http://openjdk.java.net/jeps/318> 320: Remove the Java EE and CORBA Modules <http://openjdk.java.net/jeps/320> 321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321> 323: Local-Variable Syntax for Lambda Parameters <http://openjdk.java.net/jeps/323> 324: Key Agreement with Curve25519 and Curve448 <http://openjdk.java.net/jeps/324> 327: Unicode 10 <http://openjdk.java.net/jeps/327> 328: Flight Recorder <http://openjdk.java.net/jeps/328> 329: ChaCha20 and Poly1305 Cryptographic Algorithms <http://openjdk.java.net/jeps/329> Finally, Initial TLSv1.3 implementation Released to the Open Sandbox. Please note well: this branch is under very active development and is not final by any means. Also note: by releasing this code, we are not committing a specific release or timeframe. We will continue development and fixing bugs until the code is ready for inclusion in the JDK. We welcome your feedback, more info [1] Regards, Rory [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0

[JIRA] (SLF4J-437) Create a BOM POM
by QOS.CH (JIRA) 23 May '18

23 May '18

Michael Osipov created SLF4J-437: ------------------------------------ Summary: Create a BOM POM Key: SLF4J-437 URL: https://jira.qos.ch/browse/SLF4J-437 Project: SLF4J Issue Type: Task Affects Versions: 1.8.0-beta2 Reporter: Michael Osipov Assignee: SLF4J developers list Please create a {{slf4j-bom}} POM which can be imported via dependency management. This makes consumer POM less verbose, no need to repeat version. The Spring Framework does this for example. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-412) Missing export in manifest file
by QOS.CH (JIRA) 18 May '18

18 May '18

[ https://jira.qos.ch/browse/SLF4J-412?page=com.atlassian.jira.plugin.system.… ] Björn Kautler commented on SLF4J-412: ------------------------------------- I don't think that export was corret, as there were no classes in that package in this bundle. This export was removed when the OSGi Log Service specification was properly implemented in 1.7.14. If you get the missing dependency message, then I suspect it is exactly that, you have no bundle deployed that provides the OSGi log service. So either add a bundle that provides the log service or remove this bundle from your configuration. For me in my little test project the log service is provided by the bundle {{org.apache.felix.gogo.command}}. All the popular OSGi containers should provide an implementation as you can see at [https://en.wikipedia.org/wiki/OSGi_Specification_Implementations#101:_Log_S…] > Missing export in manifest file > ------------------------------- > > Key: SLF4J-412 > URL: https://jira.qos.ch/browse/SLF4J-412 > Project: SLF4J > Issue Type: Bug > Components: osgi-over-slf4j > Affects Versions: 1.7.14, 1.7.25 > Reporter: Herve Dumont > Assignee: SLF4J developers list > > Issue is a regression from SLF4J-341. > version 1.7.13 was exporting org.osgi.service.log > starting v 1.7.14 org.osgi.service.log is not longer exported,. > bundle cannot be started due missing dependency org.osgi.service.log. > Adding > Export-Package: org.osgi.service.log;uses:="org.osgi.framework";version="1.3" > should solve the issue -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-434) Suggestion: Additional simplelogger.properties file
by QOS.CH (JIRA) 16 May '18

16 May '18

[ https://jira.qos.ch/browse/SLF4J-434?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-434: ----------------------------------------- This can be cancelled. I could make my use case expire, because it was easier to get an okay from my superiors to do the work to switch to logback, than to obtain even a documentation PR review from Ceki. > Suggestion: Additional simplelogger.properties file > --------------------------------------------------- > > Key: SLF4J-434 > URL: https://jira.qos.ch/browse/SLF4J-434 > Project: SLF4J > Issue Type: Improvement > Reporter: Joachim Durchholz > Assignee: SLF4J developers list > Priority: Minor > > Allow an additional simplelogger.properties file. > Use case: We have a simplelogger.properties in the git-managed source tree. However, we also want to have a .gitignored properties file so we can do quick local testing. > Suggestion: > Add configuration directive org.slf4j.simpleLogger.configFile. > Includes the file, overriding the settings from the source that the configFile directive was in (simplelogger.properties or system properties, whichever may be the case). > The included file must not contain another configFile directive. > My status: Discussion welcome. Willing to contribute patch if so desired. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 11 Early Access build 12 available
by Rory O'Donnell 08 May '18

08 May '18

Hi Ceki, **JDK 11 EA build 12 , *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. ** * * Newly approved Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html *Notable changes in JDK 11 EA builds since last email:* * Build 11 - see Release Notes for details. o JDK-8201315 : SelectableChannel.register may be invoked while a selection operation is in progress * Build 10 - see Release Notes for details. o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class o JDK-8189997 (not public) : Enhanced KeyStore Mechanisms o JDK-8175075 (not public) : 3DES Cipher Suites Disabled * Build 9: - see Release Notes for details. o JDK-8200152 : KerberosString uses UTF-8 encoding by default o JDK-8200458 : Readiness information previously recorded in SelectionKey ready set not preserved ** *Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1] * This draft JEP [2] proposes to deprecate the pack200 APIs and tools in the JDK. As outlined in the JEP, the usefulness of this technology have diminishing returns, the components using them are being removed and connectivity speeds have improved by leaps and bounds, since its inception. Feedback appreciated via http://mail.openjdk.java.net/pipermail/jdk-dev Regards, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html [2] https://bugs.openjdk.java.net/browse/JDK-8200752 Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0

Re: [slf4j-dev] "URI is not absolute" error in tests
by Toolforger 07 May '18

07 May '18

Sure. Would you like a PR that extends README.md with a paragraph? Am 06.05.2018 um 17:45 schrieb Ceki: > Can you please document the steps in getting the build running for the > benefit of the followers? > > On 06.05.2018 11:56, Toolforger wrote: >> Hi all, >> >> Now that I finally got the build running, I still see "URI is not >> absolute" errors in various tests in the "SLF4J Extensions Module". >> Should I worry? >> >> Regards >> Jo >> _______________________________________________ >> slf4j-dev mailing list >> slf4j-dev(a)qos.ch >> http://mailman.qos.ch/mailman/listinfo/slf4j-dev >

2 2

"URI is not absolute" error in tests
by Toolforger 06 May '18

06 May '18

Hi all, Now that I finally got the build running, I still see "URI is not absolute" errors in various tests in the "SLF4J Extensions Module". Should I worry? Regards Jo

2 1

[JIRA] (SLF4J-436) Logger name mismatch when using Spock
by QOS.CH (JIRA) 02 May '18

02 May '18

[ https://jira.qos.ch/browse/SLF4J-436?page=com.atlassian.jira.plugin.system.… ] Tobias Gruetzmacher commented on SLF4J-436: ------------------------------------------- Here is the (truncated) content of *trace* in *Util.getCallingClass()*: {noformat} org.slf4j.helpers.Util$ClassContextSecurityManager org.slf4j.helpers.Util org.slf4j.LoggerFactory x x org.slf4j.LoggerFactory$getLogger org.codehaus.groovy.runtime.callsite.CallSiteArray org.codehaus.groovy.runtime.callsite.AbstractCallSite org.codehaus.groovy.runtime.callsite.AbstractCallSite org.example.MismatchTest sun.reflect.NativeConstructorAccessorImpl sun.reflect.DelegatingConstructorAccessorImpl java.lang.reflect.Constructor org.junit.runners.BlockJUnit4ClassRunner{noformat} First column marks the entry which is selected by *getCallingClass()*, second column is the flag *isSynthetic* of that *Class<?>* object, this might be used to implement a workaround in *getCallingClass()* ... Would it be a viable solution to skip synthetic classes in this method? I wonder if it would be a good idea to also skip all those groovy frames somehow?!? > Logger name mismatch when using Spock > ------------------------------------- > > Key: SLF4J-436 > URL: https://jira.qos.ch/browse/SLF4J-436 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.7.25, 1.8.0-beta2 > Reporter: Tobias Gruetzmacher > Assignee: SLF4J developers list > Priority: Minor > > When using the Spock Framework ([http://spockframework.org/) in combination with *slf4j.detectLoggerNameMismatch* you get logger mismatch messages like this: > {noformat} > SLF4J: Detected logger name mismatch. Given name: "org.example.MismatchTest"; computed name: "org.slf4j.LoggerFactory$getLogger". > SLF4J: See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation{noformat} > It seems that Spock does some magic with its test classes... > Sample maven project attached. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-436) Logger name mismatch when using Spock
by QOS.CH (JIRA) 01 May '18

01 May '18

[ https://jira.qos.ch/browse/SLF4J-436?page=com.atlassian.jira.plugin.system.… ] Tobias Gruetzmacher commented on SLF4J-436: ------------------------------------------- After some more prodding, the culprit here isn't even spock, but in Groovy: Whenever you use Groovy's metaObject, the call to getLogger goes through some internal Groovy classes... > Logger name mismatch when using Spock > ------------------------------------- > > Key: SLF4J-436 > URL: https://jira.qos.ch/browse/SLF4J-436 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.7.25, 1.8.0-beta2 > Reporter: Tobias Gruetzmacher > Assignee: SLF4J developers list > Priority: Minor > Attachments: slf4j-spock-name-mismatch.zip > > > When using the Spock Framework ([http://spockframework.org/) in combination with *slf4j.detectLoggerNameMismatch* you get logger mismatch messages like this: > {noformat} > SLF4J: Detected logger name mismatch. Given name: "org.example.MismatchTest"; computed name: "org.slf4j.LoggerFactory$getLogger". > SLF4J: See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation{noformat} > It seems that Spock does some magic with its test classes... > Sample maven project attached. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0