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

Logging library conflict #44

Closed
Deraen opened this issue Oct 10, 2016 · 7 comments
Closed

Logging library conflict #44

Deraen opened this issue Oct 10, 2016 · 7 comments

Comments

@Deraen
Copy link

Deraen commented Oct 10, 2016

Hi,

I'm trying to use Dirac on a project which is using logback and sljf4j. Unfortunately clj-logging-config used by Dirac only supports log4j 1.

Logging dependencies:

[org.clojure/tools.logging "0.3.1"]
[ch.qos.logback/logback-classic "1.1.7"]
[org.slf4j/slf4j-api "1.7.21"]
[org.slf4j/jcl-over-slf4j "1.7.21"]
[org.slf4j/jul-to-slf4j "1.7.21"]
[org.slf4j/log4j-over-slf4j "1.7.21"]

Exception:

Error loading dirac.nrepl: java.lang.IllegalArgumentException: No matching ctor found for class clj_logging_config.log4j.proxy$org.apache.log4j.WriterAppender$ff19274a, compiling:(clj_logging_config/log4j.clj:37:18)
> java.lang.Exception: namespace 'clj-logging-config.log4j' not found, compiling:(dirac/logging.clj:1:1)

Dirac failed to require its implementation. This is likely caused by missing or wrong dependencies in your project.
Please review your project configuration with Dirac installation instructuctions here: https://github.com/binaryage/dirac#installation.
**stack trace**

Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: dirac.nrepl/middleware in this context, compiling:(/tmp/form-init8356300935810374369.clj:1:9709)
**stack trace**
@darwin
Copy link
Member

darwin commented Oct 10, 2016

Hi Deraen,

I'm not experienced in Java and Clojure logging infrastructure. I just picked org.clojure/tools.logging and clj-logging-config seemed like a convenient way how to configure my logs via code and not have to learn some arcane ways how to configure it via java config files.

Do you have any proposals what should I ideally do?

Anyways, I think I can make dependency on clj-logging-config optional. Even today you can provide :skip-logging-setup in agent and nrepl configs, but the dependencies will be still referenced (I could try to resolve them dynamically only if :skip-logging-setup is not specified)..

(if-not (:skip-logging-setup effective-config)
(logging/setup! effective-config))

@Deraen
Copy link
Author

Deraen commented Oct 10, 2016

It is a good practice that libraries do not require specific logging implementations, but instead just use some API (log4j-api, slf4-api etc) and leave it to the application to select implementation. For example both slf4j and log4j 2 provide implementations for nearly all the other logging APIs. These "bridges" take care of redirecting messages to selected implementation. All the configuration (filters, appenders) is dependent on the logging implementation. This means that libraries can't define those.

Also, log4j 1 has been deprecated in favor of log4j 2: http://logging.apache.org/log4j/1.2/. Which is one reason I wouldn't use it or clj-logging-config.

As for solution,

Is there any reason Dirac needs to use Java logging at all?
Logging can be very useful if the app needs to do:

  • audit logging (messages must not be lost)
  • messages need to be filtered
  • messages need to be sent to multiple output (logging servers, files, console, etc)
  • same format needs to be used for messages from all logging sources (app code, http server, database driver), so that this can be easily analyzed by tools

I don't think Dirac needs any of these?

In Boot the logging has been implemented by some tens lines of code which just uses print and one atom to select logging level: https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/util.clj#L21-L99. Similar implementation should work here, maybe with addition of macro which sets the color based on namespace.

@darwin
Copy link
Member

darwin commented Oct 10, 2016

Thanks for the detailed response.

Dirac Agent is a server-side component/app which should log somehow.
Dirac nRELP middleware is another component living in nREPL server.
Both use dirac.lib namespaces which are reusable components which want to do some logging as well.

I thought it is idiomatic in Clojure world to use org.clojure/tools.logging (which should be agnostic to logging implementation). I just made the mistake of bringing in clj-logging-config as a hard dependency. I wanted to customize colors and format the output.

I'm about to cut a new Dirac 0.7 release today or tomorrow. So I want to fix this for you. I'm going to keep using org.clojure/tools.logging, but will drop dependency on clj-logging-config. Will use it only if top-level app including my components explicitly asks for it.

@Deraen
Copy link
Author

Deraen commented Oct 10, 2016

Sounds good.

Using tools.logging is indeed fine (and idiomatic).

darwin added a commit that referenced this issue Oct 10, 2016
This removes remaining dependency on dirac.logging from agent.

#44
darwin added a commit that referenced this issue Oct 10, 2016
This removes remaining dependency on dirac.logging from nrepl.

#44
@darwin
Copy link
Member

darwin commented Oct 10, 2016

@Deraen I think this is enough to get rid of the blocking dependency. Would be great if you could clone dirac repo, and do lein install. This should install HEAD version of dirac library into your local maven repository and you could test it with your project. Don't expect it to talk to Dirac Chrome extension, but at least we would see if you can get past that dependency issue.

@Deraen
Copy link
Author

Deraen commented Oct 10, 2016

@darwin Yep, I can start repl now.

@darwin
Copy link
Member

darwin commented Oct 10, 2016

Cool, thanks for confirmation. Will release a new Dirac version in a few hours.

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

2 participants