On Sep 15, 3:29 am, Jeff Rose <ros...@gmail.com> wrote: > 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).
If you really need logging, then log4j is probably your best bet anyway. The master branch c.c.logging docs provide a brief log4j configuration to get people going. Though the fact that deps are directly referencing log4j is a bit of a problem since you may not be using log4j, thus to benefit from the log output of the dep, you need to go through separate configuration. Solving this was ostensibly the point of apache commons-logging (and continued in c.c.logging), to allow library writers to emit logs agnostically, leaving the actual log implementation/configuration to the runtime environment. > 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. The classpath thing is an ease-of-use consideration, and was a way to allow people to keep whatever implementation they've been using (it's also how commons-logging works). You make a good point about expecting/ configuring for one implementation but another being picked up, though this would be a problem with commons-logging as well. That said, in the master branch version it's quite easy to control which implementation will be used by calling binding or alter-var-root to change the *log-factory* var, e.g.: user=> (use 'clojure.contrib.logging) nil user=> (alter-var-root #'*log-factory* (fn [& _](java-util-logging))) #<user$eval247$reify__254 user$eval247$reify__...@4adf2940> >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. It's part about compatibility (in that people may already be using logging in their java code) and part about the fact that no one has written a fully functional, production-ready logging library. The latter makes sense considering there are plenty of java libs, but if you find a clojure logging implementation please let me know. The only pain-point that I've found is changing the level while in the repl, and log4j can reload the config file so it hasn't really been an issue for me. > > 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
