>
> > > 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 ?
>
as a (hopefully) future user of httpclient, i'd certainly like to not have
to download and use log4j with httpclient. i'm probably plugging httpclient
into an existing application, with existing logging stuff (not log4j) and
the plugable logging approach would be much better for me.
just my $0.02 :)
