I tried to update Spring boot 3.1.7 --> 3.1.8 which causes my tests to fail with --> java.lang.NoSuchMethodError: 'void org.slf4j.helpers.Util.report(java.lang.String, java.lang.Throwable)'
Spring boot 3.1.7 uses --> slf4j-api 2.0.9 and logback-classic 1.4.14 Spring boot 3.1.8 uses --> slf4j-api 2.0.11 and logback-classic 1.4.14
In slf4j-api they commented out the report method --> https://github.com/qos-ch/slf4j/blob/8c4ea8f225bd45719687849f4dc55f08028f6971/slf4j-api/src/main/java/org/slf4j/helpers/Util.java#L120 since this commit --> https://github.com/qos-ch/slf4j/commit/316b5d1727d647250ff791565650070094f5b85e
Logback-classics class LogbackServiceProvider still tries to access the uncommted function https://github.com/qos-ch/logback/blob/9078f68f49673d2163ebbaa075ec4018a6d12e54/logback-classic/src/main/java/ch/qos/logback/classic/spi/LogbackServiceProvider.java#L63
This causes these dependencies to be incompatible and causes errors in my tests. I could use the workaround to set the slf4j.version by hand back to 2.0.9, but I think the used dependencies should be compatible in the spring boot bundle.
Error lies in my opinion at slf4j-api, removing a public method in a patch release. my suggestion would be to roleback slf4j-api until logback-classic is patched.
Comment From: wilkinsona
Thanks for reporting this. It looks like the NoSuchMethodError will only occur as a symptom of another initialization failure. That would explain, I think, why we haven't seen the failure in our builds. Can you use the debugger to look at the exception that's caught in LogbackServiceProvider? It would be useful to know what the underlying problem is and if it's something that you can fix so that we can make an informed decision about rolling back the SLF4J API version and weigh up the pros and cons.
Comment From: lynxSven
In my Test its a NPE in our side.
We created a Class which should create a LogstashConfiguration. When this method in binder is called it returns null and later a NPE is raised.
But I think this is just a problem at our side, I have to look into. It just shows when the error is handled that the libraries aren't working as expected.
Comment From: wilkinsona
Thanks. Given the circumstances, I'm tempted to leave our dependencies as they are for now.
@ceki is this a known problem on the SLF4J/Logback side or would it be helpful if we opened an issue?
Comment From: ceki
@wilkinsona This looks definitely like an oversight. I will look into it shortly.
Comment From: ceki
@lynxSven SLF4J version 2.0.12 released a few moments ago should solve the problem.
Comment From: scottfrederick
Thanks for the fast response @ceki!