Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

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 wrote: > The fact that it is labeled an alpha release is

Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

I have no problem telling people that I use Log4j and that they should stop using slf4j. I've been bitten by slf4j breaking compatibility in to many debugging sessions. Upgrading from one slf4j version to the next is like stepping into a minefield blindfolded wearing earplugs. Gary On Wed, Feb 2

Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

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 be

Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

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

LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

In 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