Git Product home page Git Product logo

clj-logging-config's People

Contributors

deliminator avatar dsiegel3 avatar emlyn avatar ikitommi avatar krukow avatar malcolmsparks avatar rufoa avatar theleoborges avatar timgilbert avatar violahs avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

clj-logging-config's Issues

Is there a way around log4j.properties at initialization?

I'm noticing that a lot of libraries my app depends on tend to do some sort of log initialization that doesn't play nicely with clj-logging-config at import time.

For instance: right now, I've got an app with a method that configures logging as follows:

(defn set-logging-defaults
  "Set the logging level for the application root"
  []
  (set-loggers! :root {:level :info
                       :out :console
                       :pattern "[%p] %d{MM-dd-yyyy HH:mm:ss} | %m%n"}))

This method then gets called in a configuration method before the server starts up, e.g.:

(defn -main []
  (init/configure)
  (server/run-server #'app {:port (Integer. (or (System/getenv "PORT") "8080"))
                            :join? false}))

However, I have korma.db on the import path for my app's core namespace. The import happens before the logging configuration is executed, and I end up with the following when I launch my app (removing the korma.db import immediately removes this WARN):

log4j:WARN No appenders could be found for logger (com.mchange.v2.log.MLog).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

Is there a way around this that I haven't figured out that doesn't rely on either creating a log4j.properties file or executing (set-logging-defaults) at import time? In general, what's the recommended practice here?

with-logging-context should restore previous mapping after evaluating body

with-logging-context should behave stack-like with the MDC logging context.

For example:

(with-logging-context
{:query "a"}
(log/debug "A")
(with-logging-context
{:query "b"}
(log/debug "B"))
(log/debug "C"))

Should log:
DEBUG A (query=a)
DEBUG B (query=b)
DEBUG C (query=a)

But it instead logs
DEBUG A (query=a)
DEBUG B (query=b)
DEBUG C (query=)

pull request coming..

Remove swank-clojure dependency

It's bad style to add development-dependencies like swank-clojure directly. This breaks other people's projects when they use a different (probably newer) version of swank-clojure.

Leiningen provides two options for solving this: dev-dependencies and plugins.

dev-dependencies are like normal dependencies, but they're only included if you work on the project itself. If your project is included as a dependency in other projects, dev-dependencies are simply ignored. There might be something similar in maven.

plugins install "global" dependencies to some directory and adds them to every project leiningen manages. This enables you to install swank-clojure as a leiningen plugin and have it available on every project you work on without adding it to the dependency-list of every project.

with-logging-config always resets the log file, not appending

Hi,

I am trying to do Thread-based logging and trying to do it as follows

(with-logging-config
[:root {:out (str "/logs/"(.getName (Thread/currentThread)) ".log")
:level :info
:pattern "%d %m (%x) %n"}
"db" {:level :debug}]
--(error message)
--)

It works but i just have the latest log line in the file not all previous ones, it is not appending to existing file. I am unable to find a switch for the configuration which can append the log messages to the file.

app fails to resolve namespace when AOT compiling

Hi,

I have successfully been using clj-logging-config in my project for a few weeks now. However I hit a problem where it breaks when I AOT compile my project.

Using the namespaces is enough to cause the issue:

(ns my-app.env
  (:use 
    clojure.tools.logging
    clj-logging-config.log4j))
(set-logger!)

I then compile it using:

lein with-profile production compile :all

Then running with:

lein trampoline with-profile production run -m my-app.core 4000

Which then brings me this exception:

Caused by: java.lang.NullPointerException
    at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:332)
    at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:987)
    at clojure.lang.Namespace.find(Namespace.java:188)
    at clojure.core$find_ns.invoke(core.clj:3659)
    at clojure.core$the_ns.invoke(core.clj:3691)
    at clojure.core$ns_name.invoke(core.clj:3698)
    at my_app.env__init.load(Unknown Source)
    at my_app.env__init.<clinit>(Unknown Source)

For the time being, I had tom completely remove logging from my project since I haven't been able to figure out what's wrong with this.

Any ideas?

Can't dynamically bind non-dynamic var: clojure.contrib.pprint/*format-str*

I just updated to clojure 1.3.0 and suddenly, my logging is blowing up.

As a test, I downgraded to Clojure 1.2.0 and things seem to work.

My config is very simple:
(set-logger!
:pattern "%-5p %20.20c: %m%n"
:level :warn
:out :console
:name "triface-api-console")

Prior to the stacktrace, I get the following warnings:
Warning: default-page-width not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic default-page-width or change the name.
Warning: print-pretty not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-pretty or change the name.
Warning: print-pprint-dispatch not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-pprint-dispatch or change the name.
Warning: print-pprint-dispatch not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-pprint-dispatch or change the name.
Warning: print-right-margin not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-right-margin or change the name.
Warning: print-miser-width not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-miser-width or change the name.
Warning: print-lines not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-lines or change the name.
Warning: print-circle not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-circle or change the name.
Warning: print-shared not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-shared or change the name.
Warning: print-suppress-namespaces not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-suppress-namespaces or change the name.
Warning: print-radix not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-radix or change the name.
Warning: print-base not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic print-base or change the name.
Warning: current-level not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic current-level or change the name.
Warning: current-length not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic current-length or change the name.
Warning: format-str not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic format-str or change the name.

Any ideas?

Thanks!

Provide default initializer for all namespaces

Is it possible to add a function that will initialize sane logging defaults for all namespaces?

It seems that, at the moment, it's necessary to call (log-config/set-logger!) individually for each namespace that we want to see logs from. If logging happens in a namespace that hasn't been initialized like this, it just silently disappears. It'd be nice to be able to initialize things once and have those settings applied across the board, to all namespaces. Can this be done with the current infrastructure?

Remove swank-clojure dependency

This dependency is clearly not needed at runtime. It's helpful while developing, but just clobbers the classpath of projects using a recent release of your library.

AGPL License include in repository

It's clear from the documentation and code that clj-logging-config is licensed under EPL-1.0. At first glance, it's confusing which the library is license under.

set-logger! macro evaluates args to early

If I programmatically call set-logger! with a run-time determined argument, it's not possible to configure the root logger since the (keyword? logger) function has already been evaluated.

The (keyword? logger) function needs to be evaluated at runtime, not macro expansion time.

Ultimate incompatibility with NDC/MDC and Clojure

Since NDC and MDC are managed with a singleton class per thread that is copied from the parent thread when a new thread is created, NDC/MDC initialization is prone to capturing inappropriate contexts.

user=> (use 'clj-logging-config.log4j)
nil
user=> (require '[clojure.tools.logging :as log])
nil
user=> (with-logging-context {:partner "MP"} (log/error "Hi") (doall (doseq [_ (range 10)] (future (log/error "Hif")))))
09:46:26 ERROR         nREPL-worker-1 user                          MP   Hi
09:46:26 ERROR -agent-send-off-pool-1 user                               Hif
09:46:26 ERROR -agent-send-off-pool-2 user                               Hif
09:46:26 ERROR -agent-send-off-pool-0 user                               Hif
09:46:26 ERROR -agent-send-off-pool-1 user                               Hif
09:46:26 ERROR -agent-send-off-pool-0 user                               Hif
09:46:26 ERROR -agent-send-off-pool-8 user                          MP   Hif
09:46:26 ERROR -agent-send-off-pool-2 user                               Hif
09:46:26 ERROR -agent-send-off-pool-9 user                          MP   Hif
09:46:26 ERROR -agent-send-off-pool-8 user                          MP   Hif
09:46:26 ERROR -agent-send-off-pool-7 user                          MP   Hif
user=>

In the above example, Clojure has spawned three new threads (agent-send-off-pool-7/8/9) that have inherited the MDC setting of the parent thread (nREPL-worker-1). From this point forward, those threads (which are apt to be recycled for future-calls for agent send-offs) will start with an incorrect logging context.

This problem is fundamental to the use of org.apache.log4j.MDC/NDC (which use thread-local singletons) and clojure's thread spawning process (which is beyond the control of the user). I doubt that clj-logging-config can resolve this issue without slaving NDC/MDC to a clojure managed context (dynamic vars?) on every log call.

Thread-local logging documentation errors

(with-logging
{:root {:out "job.log" :level :debug}}
(debug "This is some debug that goes to job.log"))

Should be:

(with-logging-config
[:root {:out "job.log" :level :debug}]
(debug "This is some debug that goes to job.log"))

Multiple Appenders

The documentation section on appenders seems to mix the logger terminology up. Is it appenders or loggers that get names assigned by this lib? What if you pass in an appender instance that has already been named?

how to configure file appender?

Hi

Is there a way to have an equivalent config of the following:

log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=./log/bot1.log
# each log file max size
log4j.appender.R.MaxFileSize=100KB
# keep 10 files
log4j.appender.R.MaxBackupIndex=20

Thanks for the package!

Can't append to file

I'm new to logging in Clojure so maybe I'm missing something here, but I can't seem to get log messages appended to anything but the console.

One minor issue is that in the first example shown in the readme, the namespace declaration doesn't work (I'm using Clojure 1.2.0):

(ns my-ns
  (:use clojure.contrib.logging
    [clj-logging-config.log4j :only logger]))

java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Symbol

Adding parenthesis around logger gets us a little farther:

java.lang.IllegalAccessError: logger does not exist

Anyway, removing :only logger brings me to my main issue:

my-ns=> (set-logger! :appender (org.apache.log4j.FileAppender. (org.apache.log4j.SimpleLayout.) "test.log"))
(nil)
my-ns=> (error "Testing...")
ERROR - Testing...
nil
my-ns=> 

It seems as though no matter what I set as an appender, the log messages always go to the console.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.