Workarount to continue with log4j-2.17.0 by using slf4j18#11909
Workarount to continue with log4j-2.17.0 by using slf4j18#11909mcvsubbu wants to merge 3 commits intoapache:masterfrom
Conversation
As per suggestioin in PR 11903, attempting to use slf4j18 so that we can avoid bumping log4j version
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## master #11909 +/- ##
=============================================
- Coverage 61.35% 46.63% -14.72%
+ Complexity 1147 940 -207
=============================================
Files 2376 1780 -596
Lines 128773 93307 -35466
Branches 19906 15078 -4828
=============================================
- Hits 79007 43513 -35494
- Misses 44039 46751 +2712
+ Partials 5727 3043 -2684
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Can you fix the tests? |
| <groupId>org.slf4j</groupId> | ||
| <artifactId>slf4j-api</artifactId> | ||
| <version>2.0.9</version> | ||
| <version>1.7.25</version> |
There was a problem hiding this comment.
We cannot change slf4j, otherwise spart 3.5 will fail.
My suggestion was to try to use slf4j2 v2.0.x and log4j-slf4j18-impl as adaptor, although I'm not sure if that would work
There was a problem hiding this comment.
that is what i had tried in my first commit, but got the error:
java.lang.abstractmethoderror: receiver class org.apache.logging.slf4j.slf4jserviceprovider does not define or inherit an implementation of the resolved method 'abstract java.lang.string getrequestedapiversion()' of interface org.slf4j.spi.slf4jserviceprovider.
presumably related to https://issues.apache.org/jira/browse/LOG4J2-3370
This reverts commit de7407a.
|
Let me summarize the current state:
I don't think there is a way to keep Spark 3.5 (and therefore Java 21 support) without upgrading log4j2. What I've asked in another PR is whether this thread contention problem has been reported to log4j2 maintainers. I've made a fast search and didn't find issues related to that in their repository. I think the best solution would be to solve the thread contention issue in log4j2. We don't need to actually fix it our self, but it would be great if you could report the issue in their repo so they know it and therefore may fix it. As said in the other thread, we don't want to keep using older versions of compatible libraries due to perf regressions. That is a dangerous path that can end up having a vulnerable dependency we cannot upgrade. |
|
Discussed offline, and here is the update:
Closing this thread |
6 participants
As per suggestioin in PR 11903, attempting to use slf4j18 so that we can avoid bumping log4j version