- slf4j-dev - mailman3.qos.ch

Switch to github issue tracking
by Nikita Sheremet 31 Oct '17

31 Oct '17

Hello everyone. First of all I understand that current communication via email may have it's own benefits. But from my point of view using issues with markers (bug, feature, etc.) in github is much better. I have read the post about emailing (https://www.slf4j.org/mailing-lists.html) which tells not (!) use html in emails. First of all reading text which separate code from other text is much simpler and faster (especially when there is a language specific highlights). May be using emails with html can be a problem. But why not use github issues? You can receive notification via emails when somebody create issues or post comment. And you get all benefits from github features like markup and styling. Also github portal adds commit links to the issue discussion automatically. There is no need to manage archive emails or search into them. All of that can be done using github search features. All posts automatically sorted by issue - there is no need to search by topic in email archives. Yes may be slf4j does not have so intensive development, but nevertheless using github can increase developing process especially for new users/developers. Could you please enable issues tracking in github?

1 0

Feature Request - adding Supplier<String> for org.slf4j.Logger interface
by Nikita Sheremet 31 Oct '17

31 Oct '17

IDEA Original idea is here - https://github.com/MicroUtils/kotlin-logging The idea is to pass Supplier<String> to debug (info, error, etc.) methods instead of template string and object varargs array. KOTLIN (just for example) In kotlin it looks like that: logger.debug { "Some $expensive message!" } So you pass just function and framework decides evaluate for message producing it or not. JAVA in java it may looks like that: logger.debug(() -> "Code which produce heavy log message")); or logger.debug(() -> { return "Code which produce heavy log message" })); E.g. we put isDebugEnabled call into framework and make code cleaner. IMPLEMENTATION It is necessary to add counterpart method with Supplier<String> argument for all methods that have final String s, final Object... objects arguments in signature. DISADVANATAGES For now I can see only one - slf4j framework will require java 8 version Do you agree to add such feature? Feel free to ask any me any questions.

1 0

JDK 8u162 b01 Early Access is available on jdk.java.net
by Rory O'Donnell 27 Oct '17

27 Oct '17

Hi Ceki, *JDK 8u162 Early Access* build 01 is available at : - jdk.java.net/8/ <http://jdk.java.net/8/> Information and schedules specific to OpenJDK 8u162 release are listed here <http://openjdk.java.net/projects/jdk8u/releases/8u162.html> <http://openjdk.java.net/projects/jdk8u/releases/8u162.html> *JRE and JDK Cryptographic Roadmap* has been updated the details are here <https://www.java.com/en/jre-jdk-cryptoroadmap.html> ** *JavaOne2017* took place October 1 to 5, 2017 at San Francisco. If you were unable to attend the event or missed some talks, below you will find links to keynotes from last week that have been posted for on-demand replay: * JavaOne Opening Keynote (Monday, Oct. 2): o https://www.oracle.com/javaone/on-demand.html?bcid=5596229112001 * Oracle Code Keynote (Tuesday, Oct. 3): o https://www.oracle.com/javaone/on-demand.html?bcid=5600354378001 * JavaOne Community Keynote (Thursday, Oct. 5): o https://www.oracle.com/javaone/on-demand.html?bcid=5604479599001 Regards, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-407) Jigsaw modules contain clashing package
by QOS.CH (JIRA) 26 Oct '17

26 Oct '17

[ https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.… ] Stephen Colebourne commented on SLF4J-407: ------------------------------------------ Discussion on jigsaw-dev mailing list indicates option 2 is the way to go. So each implementation module should have a unique name. I believe this means that slf4j 1.8 branch is correct as is. http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-October/013283.html http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-October/013285.html > Jigsaw modules contain clashing package > --------------------------------------- > > Key: SLF4J-407 > URL: https://jira.qos.ch/browse/SLF4J-407 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.8.0-alpha2 > Reporter: Stephen Colebourne > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta1 > > > Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules that contain the same package, so this will be a problem. > I know that SLF4J does not intend users to load both of these modules at the same time. But the current setup means that it will be the JPMS runtime that rejects it, meaning that there is no chance for SLF4J to output a helpful message (as I believe it does today). > The solution to this would appear to be to move the `org.slf4j.impl` package to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not exported, this should not affect any user code (except code that would have been affected anyway). > I imagine this affects other slf4j artifacts. > I also note that [this module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-…] exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop do not export their package). > See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for more information on naming. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-407) Jigsaw modules contain clashing package
by QOS.CH (JIRA) 21 Oct '17

21 Oct '17

[ https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.… ] Stephen Colebourne commented on SLF4J-407: ------------------------------------------ Log4J also mentioned a use case where multiple implementations might be loaded and one selected at runtime, or perhaps even more than one used, requirements that need different module names for each implementation. SLF4J is slightly different as currently many of the implementations share the same package. The real concern here is about mistakes - where a bad module on Maven Central includes the implementation as a dependency. Linked to that is the point above about recompiling module-info to change implementation (although the command line --add-modules flag can sidestep that). The question is whether option 1 (forcing all implementations to have the same module name) is the right reaction to the concerns. Initiallly I thought the bad module case had no ability to work around it. However, it turns out there is a way to work around. You have to create an empty module with the name of the logging implementation that you don't want to satisfy the dependency. I've come to the conclusion that Maven should do this if necessary (when it sees an exclude clause). Given that there is a workaround, option 2 seems more like the way to go, although I do think we should ask the authors of JPMS on the Oracle mailing lists, > Jigsaw modules contain clashing package > --------------------------------------- > > Key: SLF4J-407 > URL: https://jira.qos.ch/browse/SLF4J-407 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.8.0-alpha2 > Reporter: Stephen Colebourne > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta1 > > > Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules that contain the same package, so this will be a problem. > I know that SLF4J does not intend users to load both of these modules at the same time. But the current setup means that it will be the JPMS runtime that rejects it, meaning that there is no chance for SLF4J to output a helpful message (as I believe it does today). > The solution to this would appear to be to move the `org.slf4j.impl` package to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not exported, this should not affect any user code (except code that would have been affected anyway). > I imagine this affects other slf4j artifacts. > I also note that [this module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-…] exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop do not export their package). > See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for more information on naming. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-407) Jigsaw modules contain clashing package
by QOS.CH (JIRA) 20 Oct '17

20 Oct '17

[ https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-407: ----------------------------------- When looking at this for Log4j I came to the conclusion that when using ServiceLoader to locate an implementation it is not necessary to require a specific module name. The only issue that comes into play would be if SLF4J has packages that it wants to only be available to an implementation. In that case, you can require that the implementation use --add-exports to export the SLF4J package(s). Then the SLF4J binding would probably need to also export them to the chosen module at runtime. In other words, I think the module-info.java file in 1.8 right now is fine. > Jigsaw modules contain clashing package > --------------------------------------- > > Key: SLF4J-407 > URL: https://jira.qos.ch/browse/SLF4J-407 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.8.0-alpha2 > Reporter: Stephen Colebourne > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta1 > > > Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules that contain the same package, so this will be a problem. > I know that SLF4J does not intend users to load both of these modules at the same time. But the current setup means that it will be the JPMS runtime that rejects it, meaning that there is no chance for SLF4J to output a helpful message (as I believe it does today). > The solution to this would appear to be to move the `org.slf4j.impl` package to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not exported, this should not affect any user code (except code that would have been affected anyway). > I imagine this affects other slf4j artifacts. > I also note that [this module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-…] exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop do not export their package). > See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for more information on naming. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] 2d4a13: start work on 1.8.0-beta1
by Ceki Gulcu 20 Oct '17

20 Oct '17

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 2d4a1324b64ab2ee6af997743e9e829c939e0438 https://github.com/qos-ch/slf4j/commit/2d4a1324b64ab2ee6af997743e9e829c939e… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-10-20 (Fri, 20 Oct 2017) Changed paths: M integration/pom.xml M jcl-over-slf4j/pom.xml M jul-to-slf4j/pom.xml M log4j-over-slf4j/pom.xml M osgi-over-slf4j/pom.xml M pom.xml M slf4j-api/pom.xml M slf4j-ext/pom.xml M slf4j-jdk14/pom.xml M slf4j-log4j12/pom.xml M slf4j-migrator/pom.xml M slf4j-nop/pom.xml M slf4j-simple/pom.xml M slf4j-site/pom.xml Log Message: ----------- start work on 1.8.0-beta1

1 0

Release of SLF4J version 1.8.0-beta0
by Ceki Gulcu 20 Oct '17

20 Oct '17

Java 9 modularization ===================== I am pleased to announce SLF4J 1.8.0-alpha0, a modularized version of slf4j compatible with Java 9 and in particular its Java Platform Module System (JSR 376), a.k.a project Jigsaw. Although there are no client facing API changes in 1.8.0-beta0 release, the static binding mechanism has been abandoned in favor of java.util.ServiceLoader introduced in Java 6. It follows that slf4j-api now requires Java 6. Just as importantly, slf4j-api version 1.8.x will no longer search for the StaticLoggerBinder class. Instead of "bindings" now slf4j-api looks for "providers" which ship with slf4j-nop-1.8.x.jar, slf4j-simple-1.8.x.jar or slf4j-jdk14-1.8.x.jar. Given that having the same package name in different modules is a showstopper in Java 9, the org.slf4j.impl package has been removed from all slf4j modules in slf4j version 1.8.0-beta0. In other words, starting with slf4j 1.8.0-beta0, "providers" will no longer act as 1.7.x/1.6.x "bindings". This is in contrast to 1.8.0-alpha series where providers also acted as bindings. For example, having slf4j-api-1.8.x.jar and slf4j-simple-1.7.x.jar on the class path will NOT work. Moreover, having slf4j-api-1.7.x.jar and slf4j-simple-1.8.x.jar on the class path will NOT work either. The only version combination for slf4j-api+slf4j-simple is version 1.8.x for both artifacts. Download ======== The relevant artifacts can be obtained via the Maven central repository. OSGi changes ============ While we expect the changes introduced in SLF4J 1.8.x to be rather transparent to users, given JPMS restrictions, implementations had to be moved from the org.slf4.impl package to packages specific to each provider. Consequently, the OSGi declarations in MANIFEST.MF files had to be modified. Our tests indicate that SLF4J version 1.8.x should work fine with OSGi. However, more in depth testing is in order. We are looking for volunteers for such tests. The slf4j-log4j12 module ======================== Due to technical reasons, slf4j-log4j12 could not be modularized in this alpha0 release. However, we expect the problem to be solved in future 1.8.x releases. Announcement mailing list ========================= You can receive SLF4J related announcements by subscribing to the SLF4J announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce You may also receive announcements via twitter: https://twitter.com/qos_ch Enjoy, -- Ceki Gülcü

1 0

CDI Producer for slf4j Logger
by Patrick Reinhart 20 Oct '17

20 Oct '17

Hi there, I wanted to ask, if you may think it would be a good idea to have an CDI Producer for slf4j Logger instances based on the target class? In our projects, we create each time such an instance fo do something like this: public class MySpecialBean { @Inject Logger myLogger; } What do you think? Best Regards Patrick

2 5

[qos-ch/slf4j] 755bf3: preparing release 1.8.0-beta0
by Ceki Gulcu 20 Oct '17

20 Oct '17

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 755bf3d42b43a82a528b182fe6667375b3920dd3 https://github.com/qos-ch/slf4j/commit/755bf3d42b43a82a528b182fe6667375b392… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-10-20 (Fri, 20 Oct 2017) Changed paths: M integration/build.xml M integration/pom.xml M jcl-over-slf4j/pom.xml M jul-to-slf4j/pom.xml M log4j-over-slf4j/pom.xml M osgi-over-slf4j/pom.xml M pom.xml M slf4j-api/pom.xml M slf4j-ext/pom.xml M slf4j-jdk14/pom.xml M slf4j-log4j12/pom.xml M slf4j-migrator/pom.xml M slf4j-nop/pom.xml M slf4j-simple/pom.xml M slf4j-site/pom.xml M slf4j-site/src/site/pages/faq.html M slf4j-site/src/site/pages/news.html Log Message: ----------- preparing release 1.8.0-beta0

1 0