- slf4j-dev - mailman3.qos.ch

[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.… ] Ceki Gülcü commented on SLF4J-407: ---------------------------------- {quote}The argument for the same module name is that only one can be active at any one time. By using the same module name, it allows the application to depend on "an implementation of SLF4J" in `module-info` without explicitly specifying which one.{quote} Interesting point. In past versions of SLF4J the logging back-end could be changed by replacing jar files for the back-end. With this version of SLF4J, i.e version 1.8.0, one would need to recompile the module-info.java file for the application. I can think of highly configurable applications such as XWiki that would want to the end-user to switch logging frameworks via a configuration switch. We could cater for this use case with a "generic" provider which reads a configuration parameter and returns the appropriate provider assuming it is available. > 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-beta0 > > > 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) 10 Oct '17

10 Oct '17

[ https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.… ] Stephen Colebourne commented on SLF4J-407: ------------------------------------------ I've written up a wiki page with SLF4J and Log4J to try and get a solid basis for logging to work https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs/_edit The key choice is with the implementation projects which are strange because only one is allowed. For SLF4J, this is projects like slf4j-nop, slf4j-simple and logback-classic. Either they all have the same module name, or they have different module names. The argument for the same module name is that only one can be active at any one time. By using the same module name, it allows the application to depend on "an implementation of SLF4J" in `module-info` without explicitly specifying which one. If using different module names for each implementation, then when the application developer writes the `module-info.java` file, they are picking an explicit implementation of the API, which can't be changed at deploy time as it would be locked into a `.class` file. My gut feeling is that the former (same module name for all implementations) is correct from a modular point of view, however developers would certainly find it surprising initially because its not how maven artifacts work. Really we could do with hearing an OSGi/JBoss modules viewpoint on the choice. See also https://issues.apache.org/jira/browse/LOG4J2-2056 > 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-beta0 > > > 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

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

[JIRA] (SLF4J-303) org.apache.log4j.Category need remove appender method
by QOS.CH (JIRA) 18 Sep '17

18 Sep '17

[ https://jira.qos.ch/browse/SLF4J-303?page=com.atlassian.jira.plugin.system.… ] Philippe commented on SLF4J-303: -------------------------------- Voted. We're having issues with an application which we migrated to logback but sadly use a paid library which use removeAllAppenders > org.apache.log4j.Category need remove appender method > ----------------------------------------------------- > > Key: SLF4J-303 > URL: https://jira.qos.ch/browse/SLF4J-303 > Project: SLF4J > Issue Type: Improvement > Components: log4j-over-slf4j > Affects Versions: 1.7.x > Environment: Operating System: Windows XP > Platform: PC > Reporter: weibo > Assignee: SLF4J developers list > > for dependency jar may contain below code: > logger.removeAllAppenders() > so please add all method of log4j.Category. > thanks -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Moving Java Forward Faster
by Rory O'Donnell 07 Sep '17

07 Sep '17

Hi Ceki, Oracle is proposing a rapid release model for Java SE going-forward. The high points are highlighted below, details of the changes can be found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2]. Under the proposed release model, after JDK 9, we will adopt a strict, time-based model with a new major release every six months, update releases every quarter, and a long-term support release every three years. The new JDK Project will run a bit differently than the past "JDK $N" Projects: - The main development line will always be open but fixes, enhancements, and features will be merged only when they're nearly finished. The main line will be Feature Complete [3] at all times. - We'll continue to use the JEP Process [4] for new features and other significant changes. The bar to target a JEP to a specific release will, however, be higher since the work must be Feature Complete in order to go in. Owners of large or risky features will be strongly encouraged to split such features up into smaller and safer parts, to integrate earlier in the release cycle, and to publish separate lines of early-access builds prior to integration. The JDK Updates Project will run in much the same way as the past "JDK $N" Updates Projects, though update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Related to this proposal, we intend to make a few changes in what we do: - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to make it easier for developers to deploy Java applications to cloud environments. We'll initially publish OpenJDK builds for Linux/x64, followed later by builds for macOS/x64 and Windows/x64. - We'll continue to ship proprietary "Oracle JDK" builds, which include "commercial features" [6] such as Java Flight Recorder and Mission Control [7], under a click-through binary-code license [8]. Oracle will continue to offer paid support for these builds. - After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds and the Oracle JDK. This will take some time, but the ultimate goal is to make OpenJDK and Oracle JDK builds completely interchangeable. - Finally, for the long term we'll work with other OpenJDK contributors to establish an open build-and-test infrastructure. This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK. Questions , comments, feedback to OpenJDK discuss mailing list [2] Rgds,Rory [1]https://mreinhold.org/blog/forward-faster [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete [4]http://openjdk.java.net/jeps/0 [5]http://openjdk.java.net/legal/gplv2+ce.html [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/ind… [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html

1 0

[JIRA] (SLF4J-300) Alternative Android implementation
by QOS.CH (JIRA) 01 Sep '17

01 Sep '17

[ https://jira.qos.ch/browse/SLF4J-300?page=com.atlassian.jira.plugin.system.… ] Lee Griffiths commented on SLF4J-300: ------------------------------------- Note, the description is out of date: # The link has changed to [https://github.com/nomis/slf4j-android] # issue #204 referenced is SLF4J-195 > Alternative Android implementation > ---------------------------------- > > Key: SLF4J-300 > URL: https://jira.qos.ch/browse/SLF4J-300 > Project: SLF4J > Issue Type: Improvement > Components: slf4j-android > Affects Versions: 1.7.x > Environment: Operating System: All > Platform: All > Reporter: Simon Arlott > Assignee: SLF4J developers list > > I've got an alternative implementation of slf4j-android that you may be interested in: https://github.com/lp0/slf4j-android > It has various features and configurability (which makes it more of a logging framework than a simple adaptation layer) as the Android logging is quite basic. > It avoids the issue in #204 and caches calls to the native isLoggable() method. > Minimal configuration to specify a default logging tag is usually required to conform to existing Android conventions (using a minimal number of logger names). -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-314) slf4j not logging VERBOSE and DEBUG messages, no matter what is Logcat's loglevel
by QOS.CH (JIRA) 31 Aug '17

31 Aug '17

[ https://jira.qos.ch/browse/SLF4J-314?page=com.atlassian.jira.plugin.system.… ] Mike Mitterer commented on SLF4J-314: ------------------------------------- Guys, [~nitin_matrix] this is a bug! If I want debug output the slf4j should give me what I want. Androids TAG-based approach is crap. This is how I set my logger: private static Logger logger = LoggerFactory.getLogger(Connection.class); setprop fails because it tells me that my name for the full class is to long. [~vyzivus] is approach is much better! > slf4j not logging VERBOSE and DEBUG messages, no matter what is Logcat's loglevel > --------------------------------------------------------------------------------- > > Key: SLF4J-314 > URL: https://jira.qos.ch/browse/SLF4J-314 > Project: SLF4J > Issue Type: Bug > Components: slf4j-android > Affects Versions: 1.7.x > Environment: Operating System: All > Platform: Other > Reporter: Mark Zalavari > Assignee: SLF4J developers list > > It seems on android platform the isLoggable() method is always returns false for VERBOSE and DEBUG (no matter what is the actal loglevel is), so it should not be called before calling Log.d and Log.v > The only slf4j version I know of where the DEBUG & VERBOSE logs are working is 1.6.1-RC1 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-418) Add JSR 305 to SLF4j
by QOS.CH (JIRA) 13 Aug '17

13 Aug '17

Erik Pragt created SLF4J-418: -------------------------------- Summary: Add JSR 305 to SLF4j Key: SLF4J-418 URL: https://jira.qos.ch/browse/SLF4J-418 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 2.0 Reporter: Erik Pragt Assignee: SLF4J developers list A few years ago, attempts have been made to implement JSR 305 in SLF4j. This was rolled back due to a Scala compiler issue, which, 5 years later, still hasn't been fixed. In the meantime, other libraries, like Guava, most of Square's libraries ([https://medium.com/square-corner-blog/rolling-out-nullable-42dd823fbd89) the Spring framework, etc, have implemented JSR 305. JSR 305 is now supported by tools like Findbugs, and languages like Kotlin, and IDEs like Eclipse and IntelliJ make use of this meta information to detect bugs. I hope that by now, we can also add JSR 305 information into SLF4j. If the Scala issue is still an issue, it seems that this issue should either be fixed by Lightbend, or they will run into issues with other frameworks anyway. Anyhow, IMO, it seems the Scala compiler should not be a reason to withhold this change from happening. The main motivation is that it will make programming in Kotlin easier (right now, types from SLF4j are platform types, and the compiler has no information if this is a nullable or non-nullable type, making SLF4j harder to use), but, as a side effect, it will help IDEs and other tooling. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Passed: leusonmario/slf4j#1 (master - 3278345)
by Travis CI 10 Aug '17

10 Aug '17

Build Update for leusonmario/slf4j ------------------------------------- Build: #1 Status: Passed Duration: 2 minutes and 21 seconds Commit: 3278345 (master) Author: Luke Cwik Message: Merge remote-tracking branch 'upstream/master' Fix merge conflict in BasicMDCAdapter.java View the changeset: https://github.com/leusonmario/slf4j/compare/d9280190fb73...32783459528c View the full build log and details: https://travis-ci.org/leusonmario/slf4j/builds/263201243?utm_source=email&u… -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications

1 0

[JIRA] (SLF4J-417) ILoggerFactory Documentation Grammer
by QOS.CH (JIRA) 09 Aug '17

09 Aug '17

Ryan McCullagh created SLF4J-417: ------------------------------------ Summary: ILoggerFactory Documentation Grammer Key: SLF4J-417 URL: https://jira.qos.ch/browse/SLF4J-417 Project: SLF4J Issue Type: Improvement Components: Core API Affects Versions: 1.7.25 Reporter: Ryan McCullagh Assignee: SLF4J developers list Priority: Trivial -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0