You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "sophie (Jira)" <ji...@apache.org> on 2020/01/04 23:18:00 UTC
[jira] [Commented] (CASSANDRA-13212) Remove hard dependency on
Logback
[ https://issues.apache.org/jira/browse/CASSANDRA-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008185#comment-17008185 ]
sophie commented on CASSANDRA-13212:
------------------------------------
Have u found a solution more better than the workaround ? any 'logback-to-slf4j' JAR?
> Remove hard dependency on Logback
> ---------------------------------
>
> Key: CASSANDRA-13212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13212
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Reporter: Michael Calderero
> Priority: Normal
>
> Hi,
> Our application is using Log4J2, SpringBoot and cassandraunit. We just upgraded to use cassandra-all version 3.0.10 (to approximately match the DataStax version wer're using) and excluded the logback-classic and logback-core dependencies from this dependency.
> However when I try to run an embedded Cassandra unit test, it always fails with the following error:
> {quote}
> Exception (java.lang.NoClassDefFoundError) encountered during startup: ch/qos/logback/core/Context
> java.lang.NoClassDefFoundError: ch/qos/logback/core/Context
> at org.apache.cassandra.service.StorageService.initServer(StorageService.java:604)
> at org.apache.cassandra.service.StorageService.initServer(StorageService.java:558)
> at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:568)
> at org.cassandraunit.utils.EmbeddedCassandraServerHelper$1.run(EmbeddedCassandraServerHelper.java:133)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: ch.qos.logback.core.Context
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 8 more
> {quote}
> I looked at the source code of StorageService and it seems like it is invoking Logback-specific classes directly, instead of SLF4J ones. This code seems to have been introduced by CASSANDRA-5883.
> I currently don't see a logback-to-slf4j bridge so seems it seems our options are to not use Cassandra (which is not possible) or to try to create a dummy bridge to route logback calls to slf4j (which then goes to Log4j2).
> Any particular reason why the Logback classes are invoked directly instead through SLF4J?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org