You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although DSBulk access the logging via the slf4j api, it makes assumptions about the underlying logger implementation being logback when it configures the logger programatically. This casuses runtime issues when DSbBulk is usded as a dependecy from another prgram that doesn't use logback.
Scenario
Using DSBulk via its BulkLoader from an environment where slf4j is bound to log4j implementation, For example:
// assume log4j-code is on the class path, then call:
BulkLoader loader = new BulkLoader(args);
loader.run();
would fail with:
Class org.apache.logging.slf4j.Log4jLogger cannot be cast to class ch.qos.logback.classic.Logger (org.apache.logging.slf4j.Log4jLogger is in unnamed module of loader 'app'; ch.qos.logback.classic.Logger is in unnamed module of loader org.apache.pulsar.common.nar.NarClassLoader @29d334c).
java.lang.ClassCastException: class org.apache.logging.slf4j.Log4jLogger cannot be cast to class ch.qos.logback.classic.Logger (org.apache.logging.slf4j.Log4jLogger is in unnamed module of loader 'app'; ch.qos.logback.classic.Logger is in unnamed module of loader org.apache.pulsar.common.nar.NarClassLoader @29d334c)
Here is the code the causes the failure (there are multiple examples in this LogSettings class where it casts to ch.qos.logback.classic.Logger ):
Configure the logger completely via the slf4j API. This may not be possible because the sl4j API does't expose methods like getAppender or getContext on the logger or reset() methof on the getILoggerFactory as logback does but there could be alternatives to those (I didn't check)
Check the implementation type at runtime and skip the configs if it is not safe to do so, somthing like:
// This is workaround to avoid runtime errors when the backfill CLI is invoked as a pulsar admin extention// where the logger type is of type org.apache.logging.slf4j.Log4jLoggerif (!(LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME) instanceofch.qos.logback.classic.Logger)) {
return;
}
Issue
Although DSBulk access the logging via the slf4j api, it makes assumptions about the underlying logger implementation being
logback
when it configures the logger programatically. This casuses runtime issues when DSbBulk is usded as a dependecy from another prgram that doesn't uselogback
.Scenario
Using
DSBulk
via itsBulkLoader
from an environment where slf4j is bound tolog4j
implementation, For example:would fail with:
Here is the code the causes the failure (there are multiple examples in this
LogSettings
class where it casts toch.qos.logback.classic.Logger
):dsbulk/workflow/commons/src/main/java/com/datastax/oss/dsbulk/workflow/commons/settings/LogSettings.java
Line 312 in 44fe069
Proposal
┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: