> > There is a setDebug call on HTTPClient.
>
> Yeah, but within httpclient itself there is no built-in mechanism to
invoke
> it at runtime.  It still dumps to stdout/stderr anyway.

+1 for getting rid of them :-)

> > Actually, what I would do eventually in the client lib is get rid of all
> the
> > logging calls, and replace them by using hooks like the
> ConnectionInterceptor.
> > That way the application gets all the significant events about what's
> going on,
> > and can decide what (or what not) to log. This is much more flexible,
and
> > allows for embedding the client cleanly.
>
> Yeah, I'm all over that.  We just need to replace the current log4j calls
> with calls to a "pluggable logger", which is potentially null.  If I get a
> chance this weekend I'll might give it a try.  I still think log4j is much
> better then the previous logging though. A generic "pluggable logger" is
> better still, thought log4j is pretty much that.

Ok, I can understand why we would want to have integrated logging as a
convinience feature for the application. However, I'd like to have the
client go into no logging by default, and have the application use the
interceptors to log what it wishes to log. I believe the current
interceptors should be enough for that task (but we can add additional hooks
if it's not the case).

What do you think ?

Craig made (on tomcat-dev) some very valid points against log4j and its
equivalents, and why the "if (debug) then log" is the right solution in many
cases.

Remy

Reply via email to