slf4j 2.0.0-alpha6 still referring to log4j 1.x
Hi Team, We are trying to upgrade slf4j to the latest version 2.0.0-alpha6 <https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0-alpha6>. We have noticed that it is still referring to log4j 1.x. We need to upgrade log4j version 2.x in our application. Looking for your support. Thanks, Vijay.
Hi Vijay, SLF4J version 2.0.0-alpha6 as well as 1.7.33 ship with the "slf4j-reload4j" module delegating to the reload4j implementation. Reload4j is a drop-in replacement for log4j version 1.2.17. See https://reload4j.qos.ch for details -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 1/21/2022 3:03 PM, Vijayendhiran M wrote:
Hi Team,
We are trying to upgrade slf4j to the latest version 2.0.0-alpha6 <https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0-alpha6>. We have noticed that it is still referring to log4j 1.x. We need to upgrade log4j version 2.x in our application. Looking for your support.
Thanks,
Vijay.
Support for SLF4J is provided by Log4j 2. However, support for 2.0.0-* has not yet been implemented because a) AFAIK SLF4J-511 has still not been fixed so it isn’t possible to get the fluent api to have correct location information and b) Ceki is known to change things that affect compatibility of implementations in alpha and beta releases since alpha and beta releases aren’t guaranteed to be production ready by definition. Ralph
On Jan 21, 2022, at 7:03 AM, Vijayendhiran M <vijayendhiran.m@globallogic.com> wrote:
Hi Team,
We are trying to upgrade slf4j to the latest version 2.0.0-alpha6 <https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0-alpha6>. We have noticed that it is still referring to log4j 1.x. We need to upgrade log4j version 2.x in our application. Looking for your support.
Thanks, Vijay. _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch <mailto:slf4j-dev@qos.ch> http://mailman.qos.ch/mailman/listinfo/slf4j-dev <http://mailman.qos.ch/mailman/listinfo/slf4j-dev>
Support for SLF4J is provided by Log4j 2. However, support for 2.0.0-* has not yet been implemented because a) AFAIK SLF4J-511 has still not been fixed so it isn’t possible to get the fluent api to have correct location information and b) Ceki is known to change things that affect compatibility of implementations in alpha and beta releases since alpha and beta releases aren’t guaranteed to be production ready by definition. Ralph
On Jan 21, 2022, at 7:03 AM, Vijayendhiran M <vijayendhiran.m@globallogic.com> wrote:
Hi Team,
We are trying to upgrade slf4j to the latest version 2.0.0-alpha6 <https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0-alpha6>. We have noticed that it is still referring to log4j 1.x. We need to upgrade log4j version 2.x in our application. Looking for your support.
Thanks, Vijay. _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch <mailto:slf4j-dev@qos.ch> http://mailman.qos.ch/mailman/listinfo/slf4j-dev <http://mailman.qos.ch/mailman/listinfo/slf4j-dev>
Ralph, If I remember correctly, you lobbied for LocationAwareLogger to admit an additional Object[] parameter. This change was made in SLF4J version 1.6 at your behest. This broke backward compatibility with 1.5 bindings. This was the only time backward compatibility was broken between 1.0 and 1.7, or in over 15 years. It is rather ironic that you should imply on this mailing list that SLF4J does not care about backward compatibility. On another register, reload4j 1.2.18.2 fixed the log4j 1.x CVEs you published recently. It was quite nice of you to file them. Thank you so much. So, as of 1.2.18.2 Vijay has the option to use reload4j as an alternative to log4j{1,2}. Best regards, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 1/23/2022 7:10 PM, Ralph Goers wrote:
Support for SLF4J is provided by Log4j 2. However, support for 2.0.0-* has not yet been implemented because a) AFAIK SLF4J-511 has still not been fixed so it isn’t possible to get the fluent api to have correct location information and b) Ceki is known to change things that affect compatibility of implementations in alpha and beta releases since alpha and beta releases aren’t guaranteed to be production ready by definition.
Ralph
On Jan 21, 2022, at 7:03 AM, Vijayendhiran M <vijayendhiran.m@globallogic.com <mailto:vijayendhiran.m@globallogic.com>> wrote:
Hi Team,
We are trying to upgrade slf4j to the latest version 2.0.0-alpha6 <https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0-alpha6>. We have noticed that it is still referring to log4j 1.x. We need to upgrade log4j version 2.x in our application. Looking for your support.
Thanks, Vijay.
Ceki, I am not talking about backward compatibility with users using the API. I am talking about compatibility with logging implementations. That has been broken several times and is why we have a log4j-slf4j-impl, a log4j-slf4j18-impl, and will now need a log4j-slf4j20-impl. It is also why Log4j cannot compile with SLF4J 1.7 versions greater than 1.7.25 since the EventData class was removed and Log4j 2 provides compatibility support for that. So that is at least 4 times compatibility between SLF4J and underlying implementations has been broken. He also has the option of using log4j-1.2-api in the upcoming 2.17.2 release. One of our PMC members just went through the exercise of migrating all of his log4j 1.2.x applications using it and was able to get all of his applications working using it. This is for both the API, configuration files, and some of the standard things users do in their code with Log4j 1.x. I do notice, however, that you did not mention anything about fixing the issue with obtaining location information in the fluent API. Have you addressed that yet? Ralph
On Jan 23, 2022, at 5:03 PM, Ceki Gülcü <ceki@qos.ch> wrote:
Ralph,
If I remember correctly, you lobbied for LocationAwareLogger to admit an additional Object[] parameter. This change was made in SLF4J version 1.6 at your behest. This broke backward compatibility with 1.5 bindings. This was the only time backward compatibility was broken between 1.0 and 1.7, or in over 15 years.
It is rather ironic that you should imply on this mailing list that SLF4J does not care about backward compatibility.
On another register, reload4j 1.2.18.2 fixed the log4j 1.x CVEs you published recently. It was quite nice of you to file them. Thank you so much. So, as of 1.2.18.2 Vijay has the option to use reload4j as an alternative to log4j{1,2}.
Best regards, -- Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 1/23/2022 7:10 PM, Ralph Goers wrote:
Support for SLF4J is provided by Log4j 2. However, support for 2.0.0-* has not yet been implemented because a) AFAIK SLF4J-511 has still not been fixed so it isn’t possible to get the fluent api to have correct location information and b) Ceki is known to change things that affect compatibility of implementations in alpha and beta releases since alpha and beta releases aren’t guaranteed to be production ready by definition.
Ralph
On Jan 21, 2022, at 7:03 AM, Vijayendhiran M <vijayendhiran.m@globallogic.com <mailto:vijayendhiran.m@globallogic.com>> wrote:
Hi Team,
We are trying to upgrade slf4j to the latest version 2.0.0-alpha6 <https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0-alpha6>. We have noticed that it is still referring to log4j 1.x. We need to upgrade log4j version 2.x in our application. Looking for your support.
Thanks, Vijay.
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
I am also talking about breaking compatibility from the point of view of implementations. You might have forgotten but LocationAwareLogger was changed at your behest. Yet, you complained about this change for years, and still do in log4j2 release announcements. EventData was authored by a certain Ralh Goers. It was removed because it had CVE-2018-8088 rated as critical. You can't invent this much irony. https://nvd.nist.gov/vuln/detail/CVE-2018-8088 https://cve.report/CVE-2018-8088 Regarding SLF4J-511, logback was exactly in the same boat and a fix was provided in commits 2d1d948c5e and 82aca890f0904. The spirit of my comments [1] in SLF4J-511 remain valid. SLF4J will not stand in your way of implementing wrappers and the issue will be fixed within a reasonable delay, by reasonable I mean within Q1 2022. [1] https://jira.qos.ch/browse/SLF4J-511?focusedCommentId=20690&page=com.atlassi... On 1/24/2022 3:45 AM, Ralph Goers wrote:
Ceki, I am not talking about backward compatibility with users using the API. I am talking about compatibility with logging implementations. That has been broken several times and is why we have a log4j-slf4j-impl, a log4j-slf4j18-impl, and will now need a log4j-slf4j20-impl. It is also why Log4j cannot compile with SLF4J 1.7 versions greater than 1.7.25 since the EventData class was removed and Log4j 2 provides compatibility support for that.
So that is at least 4 times compatibility between SLF4J and underlying implementations has been broken.
He also has the option of using log4j-1.2-api in the upcoming 2.17.2 release. One of our PMC members just went through the exercise of migrating all of his log4j 1.2.x applications using it and was able to get all of his applications working using it. This is for both the API, configuration files, and some of the standard things users do in their code with Log4j 1.x.
I do notice, however, that you did not mention anything about fixing the issue with obtaining location information in the fluent API. Have you addressed that yet?
Ralph
On Jan 23, 2022, at 5:03 PM, Ceki Gülcü <ceki@qos.ch> wrote:
Ralph,
If I remember correctly, you lobbied for LocationAwareLogger to admit an additional Object[] parameter. This change was made in SLF4J version 1.6 at your behest. This broke backward compatibility with 1.5 bindings. This was the only time backward compatibility was broken between 1.0 and 1.7, or in over 15 years.
It is rather ironic that you should imply on this mailing list that SLF4J does not care about backward compatibility.
On another register, reload4j 1.2.18.2 fixed the log4j 1.x CVEs you published recently. It was quite nice of you to file them. Thank you so much. So, as of 1.2.18.2 Vijay has the option to use reload4j as an alternative to log4j{1,2}.
Best regards, -- Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 1/23/2022 7:10 PM, Ralph Goers wrote:
Support for SLF4J is provided by Log4j 2. However, support for 2.0.0-* has not yet been implemented because a) AFAIK SLF4J-511 has still not been fixed so it isn’t possible to get the fluent api to have correct location information and b) Ceki is known to change things that affect compatibility of implementations in alpha and beta releases since alpha and beta releases aren’t guaranteed to be production ready by definition.
Ralph
On Jan 21, 2022, at 7:03 AM, Vijayendhiran M <vijayendhiran.m@globallogic.com <mailto:vijayendhiran.m@globallogic.com>> wrote:
Hi Team,
We are trying to upgrade slf4j to the latest version 2.0.0-alpha6 <https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0-alpha6>. We have noticed that it is still referring to log4j 1.x. We need to upgrade log4j version 2.x in our application. Looking for your support.
Thanks, Vijay.
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
-- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
Ceki, I am not talking about backward compatibility with users using the API. I am talking about compatibility with logging implementations. That has been broken several times and is why we have a log4j-slf4j-impl, a log4j-slf4j18-impl, and will now need a log4j-slf4j20-impl. It is also why Log4j cannot compile with SLF4J 1.7 versions greater than 1.7.25 since the EventData class was removed and Log4j 2 provides compatibility support for that. So that is at least 4 times compatibility between SLF4J and underlying implementations has been broken. He also has the option of using log4j-1.2-api in the upcoming 2.17.2 release. One of our PMC members just went through the exercise of migrating all of his log4j 1.2.x applications using it and was able to get all of his applications working using it. This is for both the API, configuration files, and some of the standard things users do in their code with Log4j 1.x. I do notice, however, that you did not mention anything about fixing the issue with obtaining location information in the fluent API. Have you addressed that yet? Ralph
On Jan 23, 2022, at 5:03 PM, Ceki Gülcü <ceki@qos.ch> wrote:
Ralph,
If I remember correctly, you lobbied for LocationAwareLogger to admit an additional Object[] parameter. This change was made in SLF4J version 1.6 at your behest. This broke backward compatibility with 1.5 bindings. This was the only time backward compatibility was broken between 1.0 and 1.7, or in over 15 years.
It is rather ironic that you should imply on this mailing list that SLF4J does not care about backward compatibility.
On another register, reload4j 1.2.18.2 fixed the log4j 1.x CVEs you published recently. It was quite nice of you to file them. Thank you so much. So, as of 1.2.18.2 Vijay has the option to use reload4j as an alternative to log4j{1,2}.
Best regards, -- Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 1/23/2022 7:10 PM, Ralph Goers wrote:
Support for SLF4J is provided by Log4j 2. However, support for 2.0.0-* has not yet been implemented because a) AFAIK SLF4J-511 has still not been fixed so it isn’t possible to get the fluent api to have correct location information and b) Ceki is known to change things that affect compatibility of implementations in alpha and beta releases since alpha and beta releases aren’t guaranteed to be production ready by definition.
Ralph
On Jan 21, 2022, at 7:03 AM, Vijayendhiran M <vijayendhiran.m@globallogic.com <mailto:vijayendhiran.m@globallogic.com>> wrote:
Hi Team,
We are trying to upgrade slf4j to the latest version 2.0.0-alpha6 <https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0-alpha6>. We have noticed that it is still referring to log4j 1.x. We need to upgrade log4j version 2.x in our application. Looking for your support.
Thanks, Vijay.
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
participants (4)
-
Ceki Gülcü -
Ralph Goers -
Ralph Goers -
Vijayendhiran M