----- Original Message -----
From: "robert burrell donkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 28, 2001 11:55 AM
Subject: Re: [httpclient] logging and testing changes
>
> On Saturday, July 28, 2001, at 06:16 AM, Scott Sanders wrote:
>
> >>> 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 :)
> >>
> >
> > I am a current user of http-client, and I also use log4j in the same
> > project. But I would rather see the interceptor approach taken, because
> > my
> > use of http-client needs to be completly transparent to the application
> > administration. This is indeed the way to go, and I intend to push
> > digester
> > in this direction as well. It can afford the same level of
functionality,
> > while allowing the end user more control.
> >
>
> there seems to me to be a common problem for most of the packages in the
> commons. everybody has their own favourite logging systems - for example
> jason (and me) love log4j, the avalon team has logkit whereas other people
> don't see why system.out and system.err shouldn't be used and so on.
> supporting all these options is not viable since it would mean too many
> dependencies but not supporting them will risk fragmentation of the code
> bases as people change stuff to use their favourite logging mechanism. for
> example, if digester doesn't allow me to use log4j for logging i'd
> probably need (sooner or later) to write my own version (supporting log4j)
> .
>
> i'd say that maybe a micro-logger commons project would provide a common
> solution. the idea would be to create a basic logging interface and then
> adapter's for people's favourite logging systems (whether log4j, LogKit,
> system.out or PrintWriter class (like digester)).
>
Isn't this exactly what JSR 47 is about ? (http://jcp.org/jsr/detail/47.jsp)
So I am +1 for this project but on the condition that it implements JSR 47
(see
http://java.sun.com/j2se/1.4/docs/api/java/util/logging/package-summary.html
for the javadoc), in the same fashion that jakarta-servletapi implements the
Servlet API ! This is because java.util.logging is included in the JDK 1.4
but we need a solution that will also work for JDK 1.1, 1.2, 1.3 ... I don't
know if JSR 47 is going to be also available as a separate jar (like the
Collection classes were available separately for JDK 1.1 users) ? If the
answer is yes, then this micro-logger project should rather be about
implementing adapter classes to support Log4j, LogKit, ... as SPI
implementations of the JSR 47 (unless it is also already done by Log4j
itself - I have not followed the Log4j forum so I don't know anything except
that Log4j was against the JSR 47).
> given that this project was *small* i don't seem why including it as a
> dependency would be a problem.
>
> comments?
>
> - robert
-Vincent
