Re: [httpclient] [VOTE] HTTP client 1.0 release

[Vincent Massol]

Title: RE: [httpclient] [VOTE] HTTP client 1.0 release

----- Original Message ----- From: Waldhoff, Rodney To: '[EMAIL PROTECTED]' Sent: Wednesday, August 01, 2001 10:09 PM Subject: RE: [httpclient] [VOTE] HTTP client 1.0 release > Ok, fine. Although the current situation is bad, I didn't > agree with the change, and vetoed it (and my position also > got some support).  However, you didn't revert the patch > as you should have. At the risk of turning this discussion much more negative, it's not at all clear to me that the "veto" notion applies here.  There was no formal vote called on this topic.  Nor is it clear to me that such a vote is warranted for what is truly a minor change (a dozen lines or so, without changing any of the outward facing functionality or the API).  Moreover, even if there was a precedence for voting on a change like this, it would seem more appropriate for that to be majority vote, not a consensus one, so the strict veto notion wouldn't apply. But that's all beside the point.  Like I've said several times, the log4j stuff isn't that important to me as much as a saw it as an improvement over the previous logging.  I've suggested several alternatives, as have others, and I've encouraged anyone who feels they can improve the situation to do so, but this still seems to be a sticking point for some reason. So for the time being, here's what I'll suggest:  Let's do what we've been talking about on the splintered log4j thread: wrapping the log4j stuff with some small local interface, use reflection to conditionally reference the log4j classes if they are available in the classpath and defaulting to stdout if they aren't.  This will avoid a direct dependency on log4j, still enable both log4j and non-log4j logging, and may set the stage for "pluggable" logging (logkit or merlin or whatever) later.  Does that sound reasonable to everyone? +1