Log4j not detected when using recent jars

270 views
Skip to first unread message

Timothy Pratley

unread,
Jan 12, 2010, 7:13:28 AM1/12/10
to Clojure
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-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

unread,
Jan 12, 2010, 9:00:47 AM1/12/10
to Clojure
This behaviour might occur due to an old Apache Commons-Logging JAR,
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

unread,
Jan 12, 2010, 12:52:48 PM1/12/10
to clo...@googlegroups.com
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

--
Baishampayan Ghose <b.g...@ocricket.com>
oCricket.com

Luc Préfontaine

unread,
Jan 12, 2010, 2:52:14 PM1/12/10
to clo...@googlegroups.com
We have been using 1.2.14 for more than a year without any glitches yet.

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

unread,
Jan 12, 2010, 3:10:09 PM1/12/10
to Clojure
Without looking too deeply, I think this is an issue with AOT
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

unread,
Jan 12, 2010, 5:16:29 PM1/12/10
to clo...@googlegroups.com
Is the performance impact of a runtime function call so critical for
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

unread,
Jan 12, 2010, 5:29:29 PM1/12/10
to clo...@googlegroups.com
> Is the performance impact of a runtime function call so critical for
> 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

unread,
Jan 12, 2010, 11:55:05 PM1/12/10
to Clojure
On Jan 12, 2:16 pm, Stuart Halloway <stuart.hallo...@gmail.com> wrote:
> 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

unread,
Jan 13, 2010, 2:47:39 AM1/13/10
to Clojure

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

unread,
Jan 14, 2010, 2:53:52 AM1/14/10
to clo...@googlegroups.com
>> 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).

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

unread,
Jan 17, 2010, 1:02:12 PM1/17/10
to Clojure

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.

http://www.assembla.com/spaces/clojure-contrib/tickets/44

Timothy Pratley

unread,
Jan 31, 2010, 1:07:57 AM1/31/10
to clo...@googlegroups.com
Thanks to Alex's patch I just wanted to report that this issue is
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.

lein.diff
project.clj
test_logging.clj
Reply all
Reply to author
Forward
0 new messages