cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Calderero (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-13212) Remove hard dependency on Logback
Date Sat, 11 Feb 2017 20:38:41 GMT
Michael Calderero created CASSANDRA-13212:
---------------------------------------------

             Summary: Remove hard dependency on Logback
                 Key: CASSANDRA-13212
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13212
             Project: Cassandra
          Issue Type: Bug
          Components: Core
            Reporter: Michael Calderero


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
(v6.3.15#6346)

Mime
View raw message