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

[Scott Sanders]

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

Rodney, the veto does apply without a vote.  You committed something that Remy feels he needs to -1, that is perfectly valid using the commit then review (CTR) model of development.  He gave a good reason, IMHO, and being a committer he is allowed to do that.  I can even agree with him to some extent.    However, I am leaning toward the compromise that is being proposed.    Remy, are you willing to allow the solution where log4j would be required to compile but not to deploy, using stdout/err as normal, or log4j if configured to do so?  It would allow others to use log4j if necessary, while keeping httpclient free of runtime dependencies.   Scott ----- Original Message ----- From: Waldhoff, Rodney To: '[EMAIL PROTECTED]' Sent: Wednesday, August 01, 2001 2: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?