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/




Reply via email to