On 12/5/06, Barrie Treloar <[EMAIL PROTECTED]> wrote:
> Classloader issues aside it's still a piece of crap. Static logging
> is bad and is an anti-pattern for component-based programming. Causes
> nothing but grief. I know you can use commons-logging as a monitor
> but no one does that. Paul Hammant's blog on why static logging is
> crap is a good read.

Got a link to this article?

I assume: http://paulhammant.com/blog/000241.html

> You want to test, have a monitor or eventing system so that you can
> get anything important to go to a console, some form or GUI, or a log
> file if you like. Going straight to logging is the extremely limited
> and makes integration a pain in the ass.

What is the standard way of doing eventing?
JMX? The console support for JMX suxors.
Alternatives?

Tempting to just use the Observer pattern. A library could have a
LogListener interface and if anyone wants to have logging, then they
can implement that interface. Pretty much what Paul's blog is saying.

Something like Lang still wouldn't use logging I suspect, but
something like BeanUtils could add a setLogListener to its primary
Bean objects instead of sitting on top of commons-logging. People
could then implement a Log4jLogListener and set that.

In Commons we could make some effort to have a bunch of LogListener
interfaces that are copy and pastes of each and are kept similar, so
that we could have Log4jLogListeners that are can be grabbed from a
wiki page and with the change of the implementing interface package
name they could be used.

Hen

Reply via email to