Hello After upgrading from Cassandra 3.6 to 3.10 I have suddenly started having errors like this:
java.lang.ClassCastException: org.slf4j.impl.JDK14LoggerAdapter cannot be cast to ch.qos.logback.classic.Logger at org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager.install(ThreadAwareSecurityManager.java:82) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:193) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601) at com.ingalys.cassandra.CassandraWrapper.<init>(CassandraWrapper.java:150) at com.ingalys.cassandra.Builder.build(Builder.java:22) at com.ingalys.soa.ServiceContainer$1.lambda$run$0(ServiceContainer.java:172) at com.ingalys.fmk2.util.ThrowingFunction.apply(ThrowingFunction.java:14) at com.ingalys.fmk2.util.PromiseImpl.lambda$thenCompose$5(PromiseImpl.java:166) I am embedding Cassandra nodes in a container of mine and it happens that there are several slf4j bindings that are transitively brought to the classpath by other dependencies. I have read that in this case slf4j chooses one of the bindings more-or-less randomly, in my case it takes the "jdk14" implementation and makes Cassandra daemon (and me too) unhappy because there is a hard-coded cast to ch.qos.logback.classic.Logger in ThreadAwareSecurityManager: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java#L83 Of course this crashes if another slf4j binding is used (by accident like me, or as a conscious choice) so I was wondering if this code should check the type of the logger before cast and adopt some fallback behavior if slf4j is not bound to logback? Thanks and regards, -- Anton PASSIOUK Horizon Software - Trade Your Way http://www.hsoftware.com/