You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Anton PASSIOUK <an...@hsoftware.com> on 2017/03/30 17:48:55 UTC
Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
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/
RE: Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
Posted by Anton PASSIOUK <an...@hsoftware.com>.
Thank you Edward.
From: Edward Capriolo [mailto:edlinuxguru@gmail.com]
Sent: Friday, March 31, 2017 4:22 PM
To: user@cassandra.apache.org
Subject: Re: Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
I created https://issues.apache.org/jira/browse/CASSANDRA-13396 for you
https://issues.apache.org/jira/browse/CASSANDRA-13396
/**
* 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 <an...@hsoftware.com>> wrote:
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/
Re: Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
Posted by Edward Capriolo <ed...@gmail.com>.
I created https://issues.apache.org/jira/browse/CASSANDRA-13396 for you
https://issues.apache.org/jira/browse/CASSANDRA-13396
/**
* 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:
> 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/
>
>
>
>
>