Library using slf4j 2.0 with application using logback-classic 1.2

[prdoyle]

I'd love to start using slf4j 2.0 in my library project, but unless I'm mistaken, that would mean any application using logback-classic 1.2 would lose the ability to see logs from my library, correct?

Is there any possibility for a compatibility shim of some sort that would permit slf4j 2.0 to work with logback-classic 1.2?

[prdoyle]

Related question here.

[ceki]

I'd love to start using slf4j 2.0 in my library project, but unless I'm mistaken, that would mean any application using logback-classic 1.2 would lose the ability to see logs from my library, correct?

Is there any possibility for a compatibility shim of some sort that would permit slf4j 2.0 to work with logback-classic 1.2?

While possible, no such shim is provided by SLF4J, as the shim would be a source of confusion itself. Upgrading to logback 1.3 or 1.4 is not an option?

[prdoyle]

My project is a library used by others. I don't have any control over the version of logback they pick. (Or their version of slf4j for that matter.)

[ceki]

If you are using the fluent API introduced in SLF4J 2.x, your downstream clients need to have SLF4J 2.0 on their class path as well as a compatible logging backend. I don't think moving to SLF4J 2.x is a big imposition on clients.

[prdoyle]

Ok. I'd probably need to wait for 2.0.6 to get this fix though.

[prdoyle]

But thinking about this a little more... what should an application developer do if they are using multiple libraries, and some use slf4j-api 1.7 while others use 2.0? Is there no plan to support such applications?

[prdoyle]

If the answer is "yep, it's a breaking change" I can live with that. Just wondering what the thinking is here.