In my experience most libraries don't even bother logging anything, and so all logging ends up being custom, giving you full control over it. What are you using that logs that you can't customise?
On Thu, Jul 12, 2012 at 10:21 AM, Elad Ben-Israel <elad.benisr...@gmail.com>wrote: > I'm getting a vibe that no one thinks this is actually a need and > wondering where my perception is skewed. In systems I worked on, we could > not control all the modules we were using and make them support pluggable > logging. I'm also wondering if this makes sense as the best practice since > I wouldn't really want to care about this all the time and pass some > logging object to every async call I'm making. > > On Wed, Jul 11, 2012 at 8:18 PM, Isaac Schlueter <i...@izs.me> wrote: > >> They could. Bunyan is pretty nice and has this capability as well. >> >> On Wed, Jul 11, 2012 at 8:51 AM, Elad Ben-Israel >> <elad.benisr...@gmail.com> wrote: >> > On Wed, Jul 11, 2012 at 6:34 PM, Guillermo Rauch <rau...@gmail.com> >> wrote: >> >> >> >> Socket.io's logger is pluggable >> > >> > >> > Unfortunately not all libraries employ pluggable logging :-) >> > >> >> >> >> >> >> >> >> On Wednesday, July 11, 2012, Elad Ben-Israel wrote: >> >>> >> >>> >> >>> >> >>> On Wed, Jul 11, 2012 at 5:25 PM, Matt <hel...@gmail.com> wrote: >> >>>> >> >>>> On Tue, Jul 10, 2012 at 6:17 PM, Elad Ben-Israel >> >>>> <elad.benisr...@gmail.com> wrote: >> >>>>> >> >>>>> Not sure exactly what use case Gaurav is interested in, but I was >> >>>>> interested in this thread because I think there is an unmet need >> around >> >>>>> logging which domain-attached context could help solve (even a >> single >> >>>>> pointer to a global instance). Logs are emitted everywhere across >> >>>>> application (and library) stack and in node, mostly via >> `console.xxx`. One >> >>>>> useful feature would be to allow, for example, correlating all >> console logs >> >>>>> emitted during the processing of an incoming request. A few logging >> >>>>> libraries do allow pushing context but they all require passing >> along some >> >>>>> state throughout the async hoops, which means modifying the way >> logging is >> >>>>> done throughout the entire stack. >> >>>> >> >>>> >> >>>> Well yes, you can't use console.log(), but "Don't Do That" anyway, >> it's >> >>>> bad practice. Look at how Haraka does logging - every log line gets >> a UUID >> >>>> associated with the current connection/transaction. It has made >> tracing >> >>>> issues with mail at Craigslist an absolute dream. >> >>>> >> >>> >> >>> Haraka is awesome but it has the privilege of being a 'mini ecosystem' >> >>> where plugins must adhere to the Haraka environment (in which case, >> use the >> >>> Haraka `this.logxxx()` functions which emit the request UUID by >> extracting >> >>> them from the current context in `this`). >> >>> >> >>> Now say you would want to create a Hakara plugin that used a library >> like >> >>> socket.io for example (just an example) which emits it's own logs - >> now what >> >>> do you do? You will need to pass the Haraka `this` pointer all the >> way to >> >>> every log callsite in the socket.io codebase. Not very practical. >> >>> >> >>> >> >>>> >> >>>> Matt. >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Elad. >> >> >> >> >> >> >> >> -- >> >> Guillermo Rauch >> >> LearnBoost CTO >> >> http://devthought.com >> >> >> > >> > >> > >> > -- >> > Elad. >> > > > > -- > Elad. >
