You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2021/02/24 14:50:01 UTC
LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware
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?
Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware
Posted by Volkan Yazıcı <vo...@gmail.com>.
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 <ra...@dslextreme.com>
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 <ck...@ckozak.net> 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?
> >>
>
>
>
Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ck...@ckozak.net> 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?
>>
Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware
Posted by Gary Gregory <ga...@gmail.com>.
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 24, 2021, 10:00 Carter Kozak <ck...@ckozak.net> 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?
> >
>
Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware
Posted by Carter Kozak <ck...@ckozak.net>.
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?
>