Logging library conflict about dirac HOT 7 CLOSED

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

from dirac.

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.

from dirac.

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.

from dirac.

Sounds good.

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

from dirac.

@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.

from dirac.

@darwin Yep, I can start repl now.

from dirac.

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

from dirac.