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

[JIRA] (SLF4J-328) Binding Ambiguity check skipped for Andriod
by QOS.CH (JIRA) 05 Apr '17

05 Apr '17

[ https://jira.qos.ch/browse/SLF4J-328?page=com.atlassian.jira.plugin.system.… ] Lin Wang commented on SLF4J-328: -------------------------------- Thanks, I tried to pick up the latest version for my android application but keep having this compilation errors: Please advise. {code:java} error: package org.slf4j does not exist import org.slf4j.Logger;{code} buildscript \{ repositories \{ mavenCentral() maven \{ url "https://mvnrepository.com/artifact/org.slf4j/slf4j-android" } maven \{ url "https://mvnrepository.com/artifact/org.slf4j/slf4j-api" } } } dependencies \{ // compile 'org.slf4j:slf4j-android:1.6.1-RC1' compile 'org.slf4j:slf4j-api:1.7.25' compile 'org.slf4j:slf4j-android:1.7.25' } > Binding Ambiguity check skipped for Andriod > ------------------------------------------- > > Key: SLF4J-328 > URL: https://jira.qos.ch/browse/SLF4J-328 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.x > Environment: Android > Reporter: Nitin Verma > Assignee: Ceki Gülcü > Priority: Critical > Fix For: 1.7.14 > > Attachments: FindStaticLoggerBinderPathsPerfTest.java > > > https://github.com/nitinverma/slf4j/commit/4d67b578fdc1cf77a0689f2efb0424f6… > As Dex cant by design have duplicate class, there would never be a 'Binding Ambiguity'. > 1. LoggerFactory.getLogger is mostly called via MainActivity. Which gives a black screen before the first activity loads. > 2. This operation takes 200-600 Inclusive CPU Time as per DDMS. > This fix get Incl CPU Time to sub 10 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-328) Binding Ambiguity check skipped for Andriod
by QOS.CH (JIRA) 05 Apr '17

05 Apr '17

[ https://jira.qos.ch/browse/SLF4J-328?page=com.atlassian.jira.plugin.system.… ] Nitin Verma commented on SLF4J-328: ----------------------------------- yes. it is in master. starting tag v_1.7.14 (https://github.com/qos-ch/slf4j/releases/tag/v_1.7.14) https://github.com/qos-ch/slf4j/commit/fc0ad8652b8485175a6295648c05425284b8… > Binding Ambiguity check skipped for Andriod > ------------------------------------------- > > Key: SLF4J-328 > URL: https://jira.qos.ch/browse/SLF4J-328 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.x > Environment: Android > Reporter: Nitin Verma > Assignee: Ceki Gülcü > Priority: Critical > Fix For: 1.7.14 > > Attachments: FindStaticLoggerBinderPathsPerfTest.java > > > https://github.com/nitinverma/slf4j/commit/4d67b578fdc1cf77a0689f2efb0424f6… > As Dex cant by design have duplicate class, there would never be a 'Binding Ambiguity'. > 1. LoggerFactory.getLogger is mostly called via MainActivity. Which gives a black screen before the first activity loads. > 2. This operation takes 200-600 Inclusive CPU Time as per DDMS. > This fix get Incl CPU Time to sub 10 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-328) Binding Ambiguity check skipped for Andriod
by QOS.CH (JIRA) 05 Apr '17

05 Apr '17

[ https://jira.qos.ch/browse/SLF4J-328?page=com.atlassian.jira.plugin.system.… ] Lin Wang commented on SLF4J-328: -------------------------------- Is this also fixed in the [https://www.slf4j.org/android/] distributions? We are currently using the 'org.slf4j:slf4j-android:1.6.1-RC1' along with 'org.apache.thrift:libthrift:0.9.2' and we are still seeing this slow ClassLoader.getResources() issue which even takes 225ms on a powerful Samsung S6 device. > Binding Ambiguity check skipped for Andriod > ------------------------------------------- > > Key: SLF4J-328 > URL: https://jira.qos.ch/browse/SLF4J-328 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.x > Environment: Android > Reporter: Nitin Verma > Assignee: Ceki Gülcü > Priority: Critical > Fix For: 1.7.14 > > Attachments: FindStaticLoggerBinderPathsPerfTest.java > > > https://github.com/nitinverma/slf4j/commit/4d67b578fdc1cf77a0689f2efb0424f6… > As Dex cant by design have duplicate class, there would never be a 'Binding Ambiguity'. > 1. LoggerFactory.getLogger is mostly called via MainActivity. Which gives a black screen before the first activity loads. > 2. This operation takes 200-600 Inclusive CPU Time as per DDMS. > This fix get Incl CPU Time to sub 10 -- 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) 02 Apr '17

02 Apr '17

[ https://jira.qos.ch/browse/SLF4J-314?page=com.atlassian.jira.plugin.system.… ] Axel Zeilner commented on SLF4J-314: ------------------------------------ After using slf4j for many years I came across the android 1.7 problems with not logging debug/trace properly. The reference to android documentation how logcat is meant to be used is of course something to consider. On the other hand the drawbacks of Android's logging system are the cause to look for the alternatives which behave like those the developer is used to from JEE and regular Java programming which are JCL or Log4j to name the most important. SLF4J has chosen to provide a facade to the native logging system which means that the developer of the SLF4J API needs to rely on the same behavior wherever his/her classes are deployed. In our case we need to deploy java classes on server and Android side which means we need to be able to use debug/trace because the classes already do and also the use of LoggerFactory.getLogger(MyClass.class) is a must. After reading long discussions on stackoverflow and many frustrated API users I just wonder why you didn't change the implementation in a way that allows the use of DEBUG just like original LogCat API does. I consider checking the loglevel in the implementation of your facade is architecturally wrong if you refer to the system's implementation which does not check either. The recommendation to switch explicitly each TAG (i.e. class being used) via System Properties to another log level is simply impractical and makes the android implementation for your API completely useless for larger app development. Some forks of the android implementation are far way better usable but simply not maintained. They use at simplest a flag (handroid) to switch the behavior in the constructor of the android.app.Application class. I would like to kindly ask to consider such an implementation change that reflects on the user's benefits. If I would receive your positive feedback I would provide a patch to the latest HEAD. > 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