tools.logging does not work if used in a project that is AOT'd.

To reproduce, in a project using tools.logging:

lein jar
lein run

I can workaround it in my project by including

(when *compile-files*
  (compile 'clojure.tools.logging)
  (compile 'clojure.tools.logging.impl))

A few of my projects are still reflecting using tools.logging 0.2.6 and slf4j-log4j12 "1.7.2".

lein check produces the following output:

...
Reflection warning, curator_clj/zookeeper.clj:1:1 - reference to field isTraceEnabled can't be resolved.
Reflection warning, curator_clj/zookeeper.clj:1:1 - reference to field isDebugEnabled can't be resolved.
Reflection warning, curator_clj/zookeeper.clj:1:1 - reference to field isInfoEnabled can't be resolved.
Reflection warning, curator_clj/zookeeper.clj:1:1 - reference to field isWarnEnabled can't be resolved.
Reflection warning, curator_clj/zookeeper.clj:1:1 - reference to field isErrorEnabled can't be resolved.
Reflection warning, curator_clj/zookeeper.clj:1:1 - reference to field isErrorEnabled can't be resolved.
...

Reflection warning, clojure/tools/logging.clj:270 - reference to field isTraceEnabled can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - reference to field isDebugEnabled can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - reference to field isInfoEnabled can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - reference to field isWarnEnabled can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - reference to field isErrorEnabled can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - reference to field isFatalEnabled can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - call to trace can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - call to debug can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - call to info can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - call to warn can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - call to error can't be resolved.
Reflection warning, clojure/tools/logging.clj:270 - call to fatal can't be resolved.

The expansion of the log macros can double-evaluate the first argument.

For example, the following call:

(log/info (expensive-call foo) bar)

Expands to this:

(let*
[logger_278auto_
(get-logger logger-factory #<Namespace scratch.core>)]
(if (enabled? logger_278auto_ :info)
(if (instance? java.lang.Throwable (expensive-call foo))
(log*
logger_278auto_
:info
(expensive-call foo)
(print-str bar))
(log*
logger_278auto_
:info
nil
(print-str (expensive-call foo) bar)))))

Note the calls to "expensive-call" both in the instance check and in the log* call.

The latest version is 0.2.4 and should reflected in the README

I think it might be useful to have spy be able to take a message to be logged in addition to the data. (or have a similar macro showing an optional message instead of the code).

(spy "doing x" (blah))
(spy :doing-x (blah) ; because it is easier to type sometimes

with spy this may conflict with the log-level.

I find this sort of function with a message useful and use it quite often. Much more often than plain logging. Generally - I would't log the code unless it logged file and line number too.

Trying to evaluate (info "Hello, World!") doesn't print to stdout when evaluating from within emacs. It works if I `lein run` however.

README.md uses the following code to show the usage of tools.logging.

(ns example.core
  (:use [clojure.tools.logging :only (info error)]))

(defn divide [one two]
  (try
    (info "Calculated" (/ one two))
    (catch Exception ex
      (error ex "There was an error in calculation"))))

If log4j.rootLogger in the given log4j.properties is updated to "ERROR, A1". "(divide 10 0)" won't evaluate "(error ex "There was an error in calculation")". The reason is that INFO logging level is lower than ERROR logging level. So the info macro will not evaluate "(/ one two)" since the specific INFO logging level is not in effect.

New tools.logging users often expect "(divide 10 0)" to produce logging with ERROR level. They are confused with the above behaviour. So I suggest to make some change to the sample code. Maybe the following code:

(ns example.core
  (:use [clojure.tools.logging :only (info error)]))

(defn divide [one two]
  (try 
    (info "Calculating" one two)
    (/ one two)
    (catch Exception ex
      (error ex "There was an error in calculation"))))

Example of error when trying to call a Logger protocol function:

java.lang.IllegalArgumentException: No implementation of method: :enabled? of protocol:
#'clojure.tools.logging.impl/Logger found for class: org.apache.log4j.Logger

The bug is the result of combining syntax-quoting with extend-type, e.g.:

`(do
   (extend-type org.apache.commons.logging.Log
     Logger
     (enabled? [logger# level#] ... )))

The syntax-quote turns the above enabled? into clojure.tools.logging/enabled? protocol function name, and then the extend-type turns that into the keyword :clojure.tools.logging/enabled?, which does not match the expected :enabled?.

Attached patch fixes this by using extend maps rather than extend-type. Also adds some tests.

The protocols which allow the main functions/macros to adapt to implementation specific logging libraries do not need to be in the clojure.tools.logging namespace since they are not intended to be used by consumers.

Plan:

• Move protocols into clojure.tools.logging.impl
• Move implementation-specific code (e.g., the extentions to the protocols) into separate namespaces, e.g., clojure.tools.logging.log4j.

The relevant patch is named tools.logging-TLOG-2-v2.diff

Changes "log" semantics to "logger" semantics.

Log protocol becomes LoggerProtocol
LogFactory protocol becomes LoggerFactoryProtocol
log-factory becomes logger-factory
impl-get-log becomes impl-get-logger
log function argument name becomes logger function argument name
log# macro autosym becomes logger# macro autosym

Per Laurent Petit