feat!: upgrade slf4j to 2.0.3

[compscidr]

Not sure if this is quite the right way of going about it, but was noticing if I updated slf4j to 2.0.x I wasn't getting logs showing up in Android any longer.

It looks like the only breaking change was in a few places Marker turned to List<Marker> so I updated throughout the code to take this wherever it was needed.

Tried it out against an android project and logging is now working again, so seems to work.

I have a feeling this will probably make things not work any longer with older slf4j though, so you may also not want to merge it, or make a different version for slf4j 2.x or something.

fix #249

[compscidr]

Okay, realized it was not working previously because it needed an implementation of org.slf4j.impl.LoggerServiceProvider which I have now added, and also added a file to the META-INF/services which tells the service loader of slf4j which implementation to try to load as a logging provider. Seems to be working now by building the jar with your script and including it in an android project using slf4j 2.0.3.

If you want to try it out, you can use:

repositories {
    maven { url 'https://jitpack.io' }
}

dependencies {
    implementation 'com.github.compscidr:logback-android:slf4f-2.0.3-SNAPSHOT'
}

[sorinirimies]

Hi, @compscidr, do you need some further testing support? I was wondering if this PR could afterwards be merged as our project relies on this library as well.
I am also asking myself whether in general, this library is still maintained or not.

[compscidr]

Hi, @compscidr, do you need some further testing support? I was wondering if this PR could afterwards be merged as our project relies on this library as well. I am also asking myself whether in general, this library is still maintained or not.

So far I've been using the changes from the PR using the jitpack build since I pushed them and it seems to be working well. It would be great to hear how others are making out with it. I did some pretty janky quickfixes to just make it api compatible - I'm curious about the markers and whether they will work well.

I think merging directly into this repo now will likely break backwards compatibility issues with pre-2.x slf4j, so it might take some careful thought if both are to be maintained together. I'm not sure on the status of this repo / whether it is being maintained (it seems like there were some recent pushes in the last year or so), but if its not, I can make a fork that's compatible with 2.x and start to maintain it. I'd likely drop older slf4j support entirely and focus only on the new stuff.

In the meantime, I just discovered the test suite errors, I'll at least get it passing those things and get the green check when I get a chance.

[MNCloudwerksTechnology]

Hey @tony19,
If this branch works and compatibility with slf4j 2.0.3 is established, would mind merging this PR? We would really like to use this library again in our Android project.

Cheers

[MNCloudwerksTechnology]

Just tested the implementation with:
implementation 'com.github.compscidr:logback-android:slf4f-2.0.3-SNAPSHOT'

It still prints out:

2022-11-03 18:38:10.225 4584-4584/com.random.package W/System.err: SLF4J: No SLF4J providers were found. 2022-11-03 18:38:10.226 4584-4584/com.random.package W/System.err: SLF4J: Defaulting to no-operation (NOP) logger implementation 2022-11-03 18:38:10.226 4584-4584/com.random.package W/System.err: SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.

No logs in either appender. Seems to me, that the provider is still not loading properly. Was that part of your fix, @compscidr?

[compscidr]

Just tested the implementation with: implementation 'com.github.compscidr:logback-android:slf4f-2.0.3-SNAPSHOT'

It still prints out:

2022-11-03 18:38:10.225 4584-4584/com.random.package W/System.err: SLF4J: No SLF4J providers were found. 2022-11-03 18:38:10.226 4584-4584/com.random.package W/System.err: SLF4J: Defaulting to no-operation (NOP) logger implementation 2022-11-03 18:38:10.226 4584-4584/com.random.package W/System.err: SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.

No logs in either appender. Seems to me, that the provider is still not loading properly. Was that part of your fix, @compscidr?

Hm that's weird, I have it working in a pretty complicated project atm - when I get a chance I'll see if I can make it work with a minimal example or something to verify there isn't some other interaction happening.

[MNCloudwerksTechnology]

Thanks that would be great.

Are you also using the following?

• Target SDK 33
• target & source-Compatibility VERSION_11

Also, thanks for your fast reply.

Cheers

[compscidr]

Thanks that would be great.

Are you also using the following?

• Target SDK 33
• target & source-Compatibility VERSION_11

Also, thanks for your fast reply.

Cheers

Okay here's a pretty minimal sample project with it working: https://github.com/compscidr/hello-kotlin-android - it does use target sdk 33 and source-compat VERSION_11

This is what it output to androids logcat:

2022-11-04 14:44:13.107 22021-22021 c.e.m.MainActivity      com.example.myapplication            D  [main                ] logger test
2022-11-04 14:44:13.107 22021-22021 c.e.m.TestComponent     com.example.myapplication            D  [main                ] testComponent: someFunction()
2022-11-04 14:44:13.107 22021-22021 c.e.l.MyClass           com.example.myapplication            D  [main                ] In the display function!

And then it also logged to papertrail which I also often use alongside.

[tony19]

Thanks for the updates! I'll merge this in 3.x, since it's technically a breaking change (as you pointed out).

[tony19]

@compscidr For some reason, this change breaks the build. I'm not sure why the CI failure didn't mark the PR. I'm reverting your changes for now in #296.

---

Found the issue: slf4jVersion was re-defined at the app level, and was pointing to an old version. Addressed that problem in #297.