I wonder how backward incompatible SLF4J 2.0 is with 1.8. That is, can we just bump the slf4j-api version in log4j-slf4j18-impl to 2.0, implement LoggingEventAware interface, and be done with it?
On Wed, Feb 24, 2021 at 4:52 PM Ralph Goers <[email protected]> wrote: > The fact that it is labeled an alpha release isn’t surprising. It took > Ceki almost 6 years to get Logback from 0.x releases to 1.0. > > To support this we would have to create an slf4j-impl-2.0 module like we > had to for 1.8, which means we will have to support 3 variations despite > SLF4J “always being backward compatible”. > > Ralph > > > > On Feb 24, 2021, at 7:59 AM, Carter Kozak <[email protected]> wrote: > > > > The slf4j API is used very widely, I don't think it's a reasonable > solution to suggest people migrate their code (and dependencies) to our > API. That said, I'm not sure how important it is for us to support each > alpha version of slf4j, considering it doesn't appear to be moving toward a > generally available release. I suppose given they're using an alpha slf4j > version, it probably is reasonable to recommend using the log4j API instead. > > > > On Wed, Feb 24, 2021, at 09:50, Volkan Yazıcı wrote: > >> In LOG4J2-2975 <https://issues.apache.org/jira/browse/LOG4J2-2975>, the > >> user tries to run SLF4J fluent API (introduced in 2.0.0-alpha) against > >> log4j-slf4j18-impl. Due to missing LoggingEventAware implementation, > source > >> location is not captured right. What shall we do? Keep on telling > people to > >> move away from SLF4J API? > >> > > >
