You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2022/09/08 16:42:54 UTC
slf4j 2.0.0 - bumpy upgrade path
slf4j 2.0.0 was recently released and it is rather different to slf4j 1.7.x.
Has anyone had any experience of this change-over yet?
Just a local update seemed to work on a project I tried it out on. That
was a change to the choice of log4j2 artifact as well -
"log4j-slf4j-impl" to "log4j-slf4j18-impl".
The question for Jena upgrading to slf4j-api 2.0.0 is what impacts it
has on client apps.
Can client apps just switch Jena versions given they themselves will be
selecting a choice of slf4j implementation or bridge to actual logging
systems?
The answer seems to be "no".
https://www.slf4j.org/faq.html#changesInVersion200
It looks like a long-timescale change over unless some kind of slf4j
adapters appear to convert 2.0.0 service loading into a 1.7 search for
StaticLoggerBinder.
So I suggest we do not upgrade, wait to see what happens in the rest of
the world, and close dependabot PR #1506.
Andy
Re: slf4j 2.0.0 - bumpy upgrade path
Posted by Andy Seaborne <an...@apache.org>.
This commit (to RDF Delta) puts the choice of slf4j 1.7.x vs 2.x in one
place: two POM properties in the top POM.
https://github.com/afs/rdf-delta/commit/90bbc25435f803c6b2fb77963870e5ede27b4a7f
Andy
On 09/09/2022 09:49, Andy Seaborne wrote:
>
>
> On 09/09/2022 00:20, Bruno Kinoshita wrote:
>>> So I suggest we do not upgrade, wait to see what happens in the rest of
>>> the world, and close dependabot PR #1506.
>>>
>>
>> Sounds good to me. We updated it in some Commons components recently, but
>> it hasn't been released yet and not sure if we will have the same issue
>> with the service loading.
>>
>> Bruno
>
> That'll be interesting to watch.
>
> The crunch is with log4j2 - the artifact name changes.
>
> logback needs a version update but not artifact name change.
>
> Andy
>
>>
>>
>> On Fri, 9 Sept 2022 at 04:43, Andy Seaborne <an...@apache.org> wrote:
>>
>>> slf4j 2.0.0 was recently released and it is rather different to slf4j
>>> 1.7.x.
>>>
>>> Has anyone had any experience of this change-over yet?
>>>
>>> Just a local update seemed to work on a project I tried it out on. That
>>> was a change to the choice of log4j2 artifact as well -
>>> "log4j-slf4j-impl" to "log4j-slf4j18-impl".
>>>
>>> The question for Jena upgrading to slf4j-api 2.0.0 is what impacts it
>>> has on client apps.
>>>
>>> Can client apps just switch Jena versions given they themselves will be
>>> selecting a choice of slf4j implementation or bridge to actual logging
>>> systems?
>>>
>>> The answer seems to be "no".
>>>
>>> https://www.slf4j.org/faq.html#changesInVersion200
>>>
>>> It looks like a long-timescale change over unless some kind of slf4j
>>> adapters appear to convert 2.0.0 service loading into a 1.7 search for
>>> StaticLoggerBinder.
>>>
>>> So I suggest we do not upgrade, wait to see what happens in the rest of
>>> the world, and close dependabot PR #1506.
>>>
>>> Andy
>>>
>>
Re: slf4j 2.0.0 - bumpy upgrade path
Posted by Andy Seaborne <an...@apache.org>.
On 09/09/2022 00:20, Bruno Kinoshita wrote:
>> So I suggest we do not upgrade, wait to see what happens in the rest of
>> the world, and close dependabot PR #1506.
>>
>
> Sounds good to me. We updated it in some Commons components recently, but
> it hasn't been released yet and not sure if we will have the same issue
> with the service loading.
>
> Bruno
That'll be interesting to watch.
The crunch is with log4j2 - the artifact name changes.
logback needs a version update but not artifact name change.
Andy
>
>
> On Fri, 9 Sept 2022 at 04:43, Andy Seaborne <an...@apache.org> wrote:
>
>> slf4j 2.0.0 was recently released and it is rather different to slf4j
>> 1.7.x.
>>
>> Has anyone had any experience of this change-over yet?
>>
>> Just a local update seemed to work on a project I tried it out on. That
>> was a change to the choice of log4j2 artifact as well -
>> "log4j-slf4j-impl" to "log4j-slf4j18-impl".
>>
>> The question for Jena upgrading to slf4j-api 2.0.0 is what impacts it
>> has on client apps.
>>
>> Can client apps just switch Jena versions given they themselves will be
>> selecting a choice of slf4j implementation or bridge to actual logging
>> systems?
>>
>> The answer seems to be "no".
>>
>> https://www.slf4j.org/faq.html#changesInVersion200
>>
>> It looks like a long-timescale change over unless some kind of slf4j
>> adapters appear to convert 2.0.0 service loading into a 1.7 search for
>> StaticLoggerBinder.
>>
>> So I suggest we do not upgrade, wait to see what happens in the rest of
>> the world, and close dependabot PR #1506.
>>
>> Andy
>>
>
Re: slf4j 2.0.0 - bumpy upgrade path
Posted by Bruno Kinoshita <ki...@apache.org>.
> So I suggest we do not upgrade, wait to see what happens in the rest of
> the world, and close dependabot PR #1506.
>
Sounds good to me. We updated it in some Commons components recently, but
it hasn't been released yet and not sure if we will have the same issue
with the service loading.
Bruno
On Fri, 9 Sept 2022 at 04:43, Andy Seaborne <an...@apache.org> wrote:
> slf4j 2.0.0 was recently released and it is rather different to slf4j
> 1.7.x.
>
> Has anyone had any experience of this change-over yet?
>
> Just a local update seemed to work on a project I tried it out on. That
> was a change to the choice of log4j2 artifact as well -
> "log4j-slf4j-impl" to "log4j-slf4j18-impl".
>
> The question for Jena upgrading to slf4j-api 2.0.0 is what impacts it
> has on client apps.
>
> Can client apps just switch Jena versions given they themselves will be
> selecting a choice of slf4j implementation or bridge to actual logging
> systems?
>
> The answer seems to be "no".
>
> https://www.slf4j.org/faq.html#changesInVersion200
>
> It looks like a long-timescale change over unless some kind of slf4j
> adapters appear to convert 2.0.0 service loading into a 1.7 search for
> StaticLoggerBinder.
>
> So I suggest we do not upgrade, wait to see what happens in the rest of
> the world, and close dependabot PR #1506.
>
> Andy
>