I have a lot of sympathy for you and your ideas, Oleg. As I mentioned
earlier, I don't mind at all if the HttpClient API will be completely
different in the next release. In my opinion there is no point in
keeping broken stuff for the sake of backward compatibility. Just give
the kid the right
Brad,
No worries about which list you subscribe to. Many on this list are
happy to answer questions such as yours.
HttpClient uses commons-logging for its configuration. If you've
configued commons-logging properly, the message can be made to go away
as you indicated. Since you already
HttpClient uses commons-logging for its configuration. If you've
configued commons-logging properly, the message can be made to go away
as you indicated. Since you already generated a wire log, presumably
you've seen the page for configuring logging. My suggestion would be to
look at
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24504.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Odi, Roland, Mike, and Adam
Thanks for the feedback. I took another look at the code this morning
and had to concede that any half-measure would hardly make things better
(or cleaner). Until HttpMethod interface is split into
HttpRequest/HttpResponse pair, decoupling of request assembly and
It strikes me personally that the warning in this particular context
is probably excessive, and it should be logged as a info or debug
message instead, but only in this particular case. If you look at the
wire log you'll notice that the server does not respond with a
Content-Length
Oleg,
Dang, you're good! You complete fixes before others can even guess at them!
-Eric.
Oleg Kalnichevski wrote:
It strikes me personally that the warning in this particular context
is probably excessive, and it should be logged as a info or debug
message instead, but only in this
