Hi ataggart, thanks for responding.  For one it made me realize that
the reason I wasn't getting any output by default is because I
happened to have log4j in my classpath for the current project (sucked
in as a dep for a sub-dependency).  It's a bit frustrating that the
behavior is different depending on which libraries are present, but I
can see how many of these issues are the consequence of being the
greatest-common-denominator for a variety of back-end libs.  This is
probably nice for compatibility with the Java world, bit it isn't an
important requirement for me so I think I'll look into doing something
else.

Cheers,
Jeff

On Sep 15, 2:38 am, ataggart <alex.tagg...@gmail.com> wrote:
> First, c.c.logging was intended as a wrapper around some java logging
> lib.  There's a plethora of them, so I saw no reason to add another.
>
> As for "simple out of the box logging", it's there (sort of) via
> java.util.logging, and it defaults writing to stdout at INFO level.
> That said, I'm inclined to use log4j.
>
> Also take a look at the master branch[1].  There are a number of
> improvements (e.g., spy now optionally takes a logging level), and the
> way underlying implementations are wired in has changed entirely.
>
> As for a set-level, I began work on adding it, but the java logging
> libraries aren't really designed to accept programmatic changes to
> logging level.  For example, some wrapper libraries (turtles all the
> way down), like SLF4J don't even expose the implementation it wraps so
> you can't drill down and fiddle with it.  Or worse, in
> java.util.logging the Logger object has a setLevel method, but that
> won't do anything unless you alter the level of the handlers that
> actually do the logging, and those handlers might actually be hanging
> off of a Logger higher up in the hierarchy.
>
> Which brings up another problem: most logging libs support a
> hierarchical model and multiple logging targets (e.g., console,
> rolling file).  When one is in the "com.example" namespace, and calls
> (set-level! :debug) should that apply to all namespaces, only that
> namespace, all subordinate namespaces?  Should all handlers be
> updated, only the ones that write to console? What if someone's using
> a tailed a log? Which ones you choose may or may not be supportable
> depending on the underlying logging implementation.
>
> In the end, java logging libs were designed to be configured by a file
> at start-up, and there's enough complexity involved that c.c.logging
> leaves that to you.  On the upside, some libs (e.g., log4j) will allow
> you to reload the logging configuration file.
>
> But as always, patches welcome.  ;)
>
> [1]http://clojure.github.com/clojure-contrib/branch-master/logging-api.html
>
> On Sep 14, 10:17 am, Jeff Rose <ros...@gmail.com> wrote:
>
>
>
> > Hi,
> >   I've been using my own wrapper for Java's built-in logging so far,
> > but today I took a look at clojure.contrib.logging because I would
> > like to start using spy.  It really seems like Clojure should have
> > some simple logging out of the box, but this is not the case yet.  Can
> > we make it a bit more user friendly?  For example, why can't it log to
> > the terminal with log level INFO by default?  Then we could just
> > require c.c.logging and use (log/info ...) or (log/spy ...).  Also,
> > there doesn't seem to be a clear way to set the log level. How about a
> > (log/set-level :debug) type of function?
>
> > I'm happy to write these functions and post them on assembla or share
> > a git repository, but I'm not sure how the process works.  Or maybe
> > I'm doing something strange.  Is everyone dropping into Java interop
> > to setup logging for every script?
>
> > -Jeff

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to