cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Hubert (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
Date Mon, 04 Sep 2017 12:40:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152569#comment-16152569
] 

Eric Hubert commented on CASSANDRA-13396:
-----------------------------------------

We faced the same underlying issue after upgrading from Cassandra 3.9 to 3.11.0 when using
Cassandra embedded for integration testing using JUnit. 
As our application uses a different logging backend and we did not want to switch it and provide
appropriate redundant configuration for logback, we excluded logback dependencies and only
provided our implementation to also avoid any warnings about duplicate bindings. This setup
worked fine with Cassandra 3.9, but fails with Cassandra >= 3.10; the server does not startup,
because of the missing classes. So in this case any patch working with instanceof checks still
attempting to load those classes without specific try/catch would obviously also fail. 

In addition to SMAwareReconfigureOnChangeFilter in org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager.install()
using multiple logback internals (added with CASSANDRA-12535) I also found the change with
CASSANDRA-12509 adding ch.qos.logback.core.hook.DelayingShutdownHook in StorageService#initServer
problematic.
Would it be an alternative to handle all access to the underlying logging implementation via
reflection? 
E.g. attempting to load logback classes and only if this does not fail, perform implementation
specific actions via reflection (otherwise log a warning about missing logback presence, which
can be ignored in integration test setups). We are mostly talking about one-time initialization,
so the performance impact should be really negligible.
This solution would require users to properly exclude logback logging libs if they want to
use other sf4j implementation bindings. Providing multiple logging implementations with sl4fj
bindings anyway triggers a warning which should be handled.

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> ----------------------------------------------------------------
>
>                 Key: CASSANDRA-13396
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Edward Capriolo
>            Assignee: Eugene Fedotov
>            Priority: Minor
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message