I created https://issues.apache.org/jira/browse/CASSANDRA-13396 for you 


* The purpose of this class is
*/ this purpose of this class is ...what ? this class is who? sicka sicka slim shady.

On Thu, Mar 30, 2017 at 1:48 PM, Anton PASSIOUK <anton.passiouk@hsoftware.com> wrote:

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:


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,
Horizon Software - Trade Your Way