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