Log4j not detected when using recent jars
Timothy Pratley
GOSUB raised this on IRC and I'm stumped as to the behavior, can
anyone help shed some light?
In order to reproduce he provided a leiningen project:
http://github.com/ghoseb/test-logging
Now running a REPL from those dependencies (note you can just run lein
deps; lein repl I am just listing the jars here to show nothing to
do with lein):
~/test-logging/lib$ java -cp
clojure-1.1.0-master-20091231.150150-10.jar:clojure-contrib-1.1.0-master-20100111.160148-18.jar:log4j-1.2.14.jar
clojure.main
Clojure 1.1.0-master-SNAPSHOT
user=> (use 'clojure.contrib.logging)
nil
user=> *impl-name*
"java.util.logging"
;;;; log4j was not detected
user=> (import (java.util.logging Logger Level))
java.util.logging.Level
;;;; log4j is on the classpath! furthermore you can set log4j using
(log4j-logger) though you have to switch to the
clojure.contrib.logging namespace because it is private. That seems to
indicate util.logging was never attached (or it would throw an
exception when trying to attach log4j.
However, when I ran the same test with the latest builds from git:
$ java -cp clojure/clojure.jar:clojure-contrib/clojure-contrib.jar:test-logging/lib/log4j-1.2.14.jar
clojure.main
Clojure 1.2.0-master-SNAPSHOT
user=> (use 'clojure.contrib.logging)
nil
user=> *impl-name*
"org.apache.log4j"
;;;; log4j as expected
Unfortunately I can't find these as snapshots so there seems to be no
lein friendly solution just yet. clojure 1.2.0-master-SNAPSHOT exists,
but not clojure-contrib 1.2.0-master-SNAPSHOT yet.
So coming back to the issue of why the strange behavior in the first
place... I looked at the git history of c.c.logging and nothing has
changed in there since Aug 19 2009, so I would have thought c.c
1.1.0-master-SNAPSHOT.jar would be current (it only just got released)
which seems to indicate something in Clojure itself has changed this
behavior.
Does anyone have any thoughts on why this is happening and whether
there is a solution?
Regards,
Tim.
Shantanu Kumar
several of which have had classpath / class-loading issues. Just a
thought.
Regards,
Shantanu
On Jan 12, 5:13 pm, Timothy Pratley <timothyprat...@gmail.com> wrote:
> Hi,
>
> GOSUB raised this on IRC and I'm stumped as to the behavior, can
> anyone help shed some light?
> In order to reproduce he provided a leiningen project:http://github.com/ghoseb/test-logging
>
> Now running a REPL from those dependencies (note you can just run lein
> deps; lein repl I am just listing the jars here to show nothing to
> do with lein):
> ~/test-logging/lib$ java -cp
> clojure-1.1.0-master-20091231.150150-10.jar:clojure-contrib-1.1.0-master-20 100111.160148-18.jar:log4j-1.2.14.jar
Baishampayan Ghose
> This behaviour might occur due to an old Apache Commons-Logging JAR,
> several of which have had classpath / class-loading issues. Just a
> thought.
Which is the recommended latest version of log4j? As I can see, 2.0 is
too experimental and 1.3 has been made obsolete.
I tried using 1.2.14 because 1.2.15 was bringing in a truck load of
dependencies.
Regards,
BG
--
Baishampayan Ghose <b.g...@ocricket.com>
oCricket.com
Luc Préfontaine
Luc
On Tue, 2010-01-12 at 23:22 +0530, Baishampayan Ghose wrote:
On Tuesday 12 January 2010 07:30 PM, Shantanu Kumar wrote: > This behaviour might occur due to an old Apache Commons-Logging JAR, > several of which have had classpath / class-loading issues. Just a > thought. Which is the recommended latest version of log4j? As I can see, 2.0 is too experimental and 1.3 has been made obsolete. I tried using 1.2.14 because 1.2.15 was bringing in a truck load of dependencies. Regards, BG -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ataggart
compiling. As the c.c.logging docs note, the logging impl is chosen
at macro-expansion-time. If contrib is fully AOTC'd, then that's when
the logging impl will be chosen. There's an assembla ticket on it:
https://www.assembla.com/spaces/clojure-contrib/tickets/44
On Jan 12, 4:13 am, Timothy Pratley <timothyprat...@gmail.com> wrote:
> Hi,
>
> GOSUB raised this on IRC and I'm stumped as to the behavior, can
> anyone help shed some light?
> In order to reproduce he provided a leiningen project:http://github.com/ghoseb/test-logging
>
> Now running a REPL from those dependencies (note you can just run lein
> deps; lein repl I am just listing the jars here to show nothing to
> do with lein):
> ~/test-logging/lib$ java -cp
> clojure-1.1.0-master-20091231.150150-10.jar:clojure-contrib-1.1.0-master-20 100111.160148-18.jar:log4j-1.2.14.jar
Stuart Halloway
logging that we need to do this at macro-expansion-time? I would like
for logging to be less magical in its implementation.
Stu
Richard Newman
> logging that we need to do this at macro-expansion-time? I would
> like for logging to be less magical in its implementation.
I think Alex's goal was to approach the near-zero cost of Java logging
implementations when logging doesn't fire.
People really care about this stuff.
http://surguy.net/articles/removing-log-messages.xml
http://www.infoq.com/news/2007/08/logback
I have to say that I've done a lot of work on throughput-sensitive
code, and if there was even the slightest inkling that c.c.logging was
hogging milliseconds, I'd simply switch to using a Java logging
implementation directly. After all, it's not hard to write a trivial
macro around log4j.
When you have 10ms to respond to a request, and you have to log a few
hundred lines along the way, you don't want to pay for a few hundred
function calls and var lookups. My first link above shows someone
actually modifying bytecode to remove even the nanosecond costs. I'm
not that bad, at least :)
ataggart
> Is the performance impact of a runtime function call so critical for
> logging that we need to do this at macro-expansion-time?
Yes, insofar as I don't want performance impact to discourage people
from peppering their code with (disabled) log messages. Richard
covers the case pretty well.
> I would like for logging to be less magical in its implementation.
I don't see the leveraging of macro evalutaion to be "magic"; I view
it as a great advantage of clojure to not be limited to only compile-
time and run-time (given the recent AOTC-compatibility demands, not
everyone agrees).
Take a look at the java code that commons-logging needs to pick the
right implementation at runtime; it's way more complex and magical
than what c.c.logging does.
Shantanu Kumar
On Jan 12, 10:52 pm, Baishampayan Ghose <b.gh...@ocricket.com> wrote:
> On Tuesday 12 January 2010 07:30 PM, Shantanu Kumar wrote:
>
> > This behaviour might occur due to an old Apache Commons-Logging JAR,
> > several of which have had classpath / class-loading issues. Just a
> > thought.
>
> Which is the recommended latest version of log4j? As I can see, 2.0 is
> too experimental and 1.3 has been made obsolete.
>
> I tried using 1.2.14 because 1.2.15 was bringing in a truck load of
> dependencies.
The following combo has worked fine for me in dev and production:
Commons Logging - 1.1.1 (it uses Log4j or java.util.logging as
underlying implementation)
Log4j - 1.2.14
If it doesn't work for you with c.c.logging, then i'd suggest you try
using Commons-Logging directly.
Regards,
Shantanu
Stuart Halloway
>
> I don't see the leveraging of macro evalutaion to be "magic"; I view
> it as a great advantage of clojure to not be limited to only compile-
> time and run-time (given the recent AOTC-compatibility demands, not
> everyone agrees).
Having considered it a little more I agree with you on this. But maybe
the AOTC side would prefer a solution that uses eval instead of
macroexpansion. :-)
ataggart
On Jan 13, 11:53 pm, Stuart Halloway <stuart.hallo...@gmail.com>
wrote:
I submitted a patch that manages to do both, depending on the context.
Timothy Pratley
resolved when using 1.2.0-master.
lein repl runs 1.1.0 even if you list 1.2.0 as your dependency. To get
around this you have two options:
1) modify lein with the attached lein.diff, this will start the repl
with the dependency you specify
tpratley@apis:~/test-logging$ lein repl
Clojure 1.2.0-master-SNAPSHOT
user=> (use 'clojure.contrib.logging)
nil
user=> *impl-name*
"org.apache.log4j"
2) use lein uberjar or lein run (see attached project and main for convenience)
tpratley@apis:~/test-logging$ lein run
org.apache.log4j
Regards,
Tim.