Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DSBulk dependency on logback implementation #465

Open
aymkhalil opened this issue Mar 14, 2023 · 0 comments
Open

DSBulk dependency on logback implementation #465

aymkhalil opened this issue Mar 14, 2023 · 0 comments

Comments

@aymkhalil
Copy link

aymkhalil commented Mar 14, 2023

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 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 ):

Proposal

  • 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.Log4jLogger
if (!(LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME) instanceof ch.qos.logback.classic.Logger)) {
            return;
}

┆Issue is synchronized with this Jira Task by Unito

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant