You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Endre Stølsvik (JIRA)" <ji...@apache.org> on 2006/11/28 15:02:21 UTC
[jira] Created: (HTTPCLIENT-609) Use TRACE logging instead of DEBUG
for the absolute nitty-gritties
Use TRACE logging instead of DEBUG for the absolute nitty-gritties
------------------------------------------------------------------
Key: HTTPCLIENT-609
URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
Project: HttpComponents HttpClient
Issue Type: Improvement
Affects Versions: 3.1 Beta 1
Environment: n/a
Reporter: Endre Stølsvik
[This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
Candidates for TRACE level include:
* httpclient.wire.*
* org.apache.commons.httpclient.params.DefaultHttpParams
* org.apache.commons.httpclient.HttpMethodBase
* .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Changing stringpart attributes
Posted by "Gerdes, Tom" <TG...@OldRepublicTitle.com>.
I am trying to use the example that shows how to use the RequestEntity.
I am trying to set my string parts to not send the "Content-Type",
"charset", or "Content-Transfer-Encoding" for my stringparts. How do
set the individual parts before setting the RequestEntity.
Below I have provided a snippet of my code. I do appreciate gratefully
any help on this you can offer.
PostMethod post1 = new PostMethod("https://ecf.ksb.uscourts.gov/" +
theUrl);
post1.setRequestHeader("Accept", "image/gif, image/x-xbitmap,
image/jpeg, image/pjpeg, application/x-shockwave-flash,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, */*");
post1.setRequestHeader("Referer", HTTPS_SERVER);
post1.setRequestHeader("Accept-Language", "en-us");
post1.setRequestHeader("User-Agent", "Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; SV1; .NET CLR 1.1.4322)");
post1.setRequestHeader("Host", "ecf.ksb.uscourts.gov");
post1.setRequestHeader("Connection", "Keep-Alive");
Part[] parts = { new StringPart("login", Login),
new StringPart("key", Password),
new StringPart("clcode", "")
};
for(int i=0; i<2; i++){ parts[i].setTransferEncoding(null);
parts[i].setContentType(null);
parts[i].setCharSet(null);
}
post1.setRequestEntity( new MultipartRequestEntity(parts,
post1.getParams()) );
I received a compile error as follows when I tried to compile this code.
BDKCWYAJ.java:122: cannot resolve symbol
symbol : method setCharSet (<nulltype>)
location: class org.apache.commons.httpclient.methods.multipart.Part
parts[i].setCharSet(null);
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-609) Use TRACE logging instead of DEBUG
for the absolute nitty-gritties
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=all ]
Oleg Kalnichevski updated HTTPCLIENT-609:
-----------------------------------------
Fix Version/s: 4.0 Alpha 1
Priority: Minor (was: Major)
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-609) Use TRACE logging instead of
DEBUG for the absolute nitty-gritties
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12453981 ]
Roland Weber commented on HTTPCLIENT-609:
-----------------------------------------
Hello Endre,
you are answering most of your suggestions yourself. Let's start with the last one, the different logger roots. That issue is known as HTTPCLIENT-497. Unfortunately, we missed it for 3.0 as well as 3.1 and can't change it now in 3.x without breaking compatibility. That's a clear wontfix.
For the rest, we have only two developer log levels to choose from, and we must use them carefully. For example, the wire log which you mention uses DEBUG for the status/response and header lines and TRACE for the message entities. That's because we want to be able to get a wire log of the headers without potentially dumping megabytes of binary data we're not interested in. Other parts of HttpClient may face similar tradeoffs.
The developer log levels are there so we, the developers, can get information we require to help users when debugging problems in various places throughout the HttpClient code. I think it is not undue that we are allowed to use two different developer log levels everywhere in order to reduce the logging noise where appropriate. If you decide to switch on DEBUG traces for _all_ of HttpClient, it's only fair that you suffer the consequences. I don't think we should have to restrain ourselves to all-or-nothing logging for DefaultHttpParams or HttpMethodBase or any other part of HttpClient because you're only interested in some of the log messages and don't want to bother with configuring your logging framework accordingly.
Saying that, if you feel there are parts of the code where we _locally_ used the two developer log levels inappropriately, or where log message phrasing could be improved, we'll happily review, discuss, and accept patches :-) I'm afraid we don't have the personpower available to perform a review of log levels for the old code base just for the fun of it. HttpClient 3.x is on life support because we are focusing our efforts on HttpComponents 4.0.
cheers,
Roland
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Resolved: (HTTPCLIENT-609) Use TRACE logging instead of
DEBUG for the absolute nitty-gritties
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-609.
------------------------------------------
Resolution: Fixed
Fix Version/s: (was: 4.0 Final)
4.0 Alpha 1
No more annoying and completely useless TRACEs. HttpClient now produces much more conciser logs
Oleg
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-609) Use TRACE logging instead of
DEBUG for the absolute nitty-gritties
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12454318 ]
Ortwin Glück commented on HTTPCLIENT-609:
-----------------------------------------
Endre,
It would help a lot if you attached to this issue a diff -u with your suggested trace logs. It should generally not be a problem for us to move some of the log down to TRACE level. Personally I favour the finer level granularity especially in large systems that use lots of components (see JBoss for instance). It allows to dig deep into the inner workings if necessary but keeps log down normally.
Ortwin
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-609) Use TRACE logging instead of DEBUG
for the absolute nitty-gritties
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber updated HTTPCLIENT-609:
------------------------------------
Fix Version/s: (was: 4.0 Alpha 1)
4.0 Final
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
> Priority: Minor
> Fix For: 4.0 Final
>
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-609) Use TRACE logging instead of
DEBUG for the absolute nitty-gritties
Posted by "Endre Stølsvik (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12454311 ]
Endre Stølsvik commented on HTTPCLIENT-609:
-------------------------------------------
@Roland: I don't quite see what you're answering/commenting - did you read the entire description?!
I did NOT at ANY POINT say that you should stop using DEBUG: I've however not seen a single log-line from httpclient that outputs on TRACE. (Full wire-dump doesn't belong in DEBUG, IM(F)O)
In my description, I try to point out that I'd appreciate IF you DID use TRACE "somewhat more extensively" (given that it isn't used at all now, AFAICS).
And I came up with some quick candidates for which loglines that would be better sent to TRACE than DEBUG.
Given that I do not suggest that you delete one single log-statement, only "downgrade" some loglines from DEBUG to TRACE, I do not understand where you're coming from in your comment at all.
Also, I firmly believe that you folks should think of "the developers" not as yourself, but as the users of your library. There are many more of the latter than the former. However, given, again, that I do not suggest that you delete one single logline, I can't seem to get why not both camps could be pleased in this particular situation.
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-609) Use TRACE logging instead of
DEBUG for the absolute nitty-gritties
Posted by "Endre Stølsvik (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12454563 ]
Endre Stølsvik commented on HTTPCLIENT-609:
-------------------------------------------
Yes it clarifyes things a good bit. I guess I didn't realize the extent to which 3.x is "abandoned". Looking forward to a new'n'fresh 4.0, then! :) (with new'n'fresh bugs?! :) )
I guess simply coming up with an "exact" set of log-lines that could do with trace doesn't cut it? It has to be actual patches? (Setting up a new project just takes some time..)
If you'd just set the one log-line that dump the wire (Onto logger "httpclient.wire.content") to do log.trace(..) instead of log.debug(..) next time you're around that code, that would help a lot, I believe.
(Actually, the number of bytes read in one chunck could be nice to have output on debug, in addition to all the actual wire content ouput on trace - this would give a nice interleaving effect with the processing of the body of the response, so that _my_ debug or trace lines was interleaved with the actual TCP connection "chunk" fetching..).
I'll try to come up with a patch for some more.
NB/PS: Once again, I actually think that _extensive_ logging og httpclient rocks. Having the actual wire-content available in such a nice output is really nice. It's just "a bit" on the verbose side when things actually are working!
Thanks,
Endre.
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-609) Use TRACE logging instead of
DEBUG for the absolute nitty-gritties
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12454408 ]
Roland Weber commented on HTTPCLIENT-609:
-----------------------------------------
Hello Endre,
yes, I read your entire description at least twice before answering. It does not mention anywhere that TRACE level is not used at all. If that is indeed the case (I haven't checked) I agree that this could be improved by making use of both log levels. Remember my invitation to provide patches?
Your examples include wire logging, which is exactly the place where I know we've been using both levels. The other specific examples are not DEBUG statements that should be downgraded, but whole classes - which I interpreted as a request to downgrade all DEBUG statements in those classes. Just moving all log/trace statements of a whole class from DEBUG to TRACE is imho not an improvement. If all output is currently at DEBUG level, it's not a deterioration either, I'll grant you that. It's just work that somebody has to do.
What you actually suggest is that we review all DEBUG level log statements and decide which of them should be downgraded. That is a _lot_ of work, and we already have more work on our list than can be achieved in a reasonable amount of time by those active developers we have. Remember my invitation to provide patches? Reviewing patches is work as well, but it's something I am willing to spend time on.
I have adopted the terminology which is commonly used on our mailing lists and in our wiki. Developers are folks working on our code base, users are folks using our code base. We put a lot of effort into keeping our users happy and satisfied. Logging is one of the tools we require to do that. But it's not a core functionality that is broken and needs fixing. It could be improved all right. The question is: who's going to spend the time for doing that?
Since you're probably not familiar with our staffing situation, here is a short overview. We have one and a half active developers. Since about a year ago, we are putting our efforts into a _complete_ overhaul of the API and code base, to become HttpComponents 4.0. We've made some progress, but we're still months if not years away from even a beta of HttpClient 4.0. There is a reason why we overhaul the API completely: the 3.x API is broken by design. We've put in as much functionality as can reasonably be put in (maybe even more), but we can't continue along that road. The code needs a complete rework, and that's what we're doing. Which means that 3.x is a legacy code base into which we'll put as much effort as needed, but as little effort as possible.
We are all quite willing to keep both camps happy. To keep "our" camp happy, all you have to do is find someone who's going to submit patches. Both Oleg and I, and probably also some of the less active committers, will gladly spend our time on reviewing such patches so they can be integrated into the code base. And we'll do that out of respect for the effort of whoever it is that comes up with the patches. What you can not expect Oleg or me to do is to spend our limited time on cosmetic improvements of the legacy code base, while the todo list for the new code base is growing from months to years. If something is broken in 3.x, we'll fix it. If somebody submits patches for improvements, we'll review them to get them in as quickly as possible. But we're not going to do code reviews for mere improvements.
I hope this clarifies things a bit. My response was not meant to imply your suggestions are unreasonable. I rather wanted to point out that they are cosmetic in nature, have a minimal priority on our list, and there's nobody at hand to do the work. If anyone steps forward to help maintain the legacy code base, we'll gladly support such effort.
cheers,
Roland
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-609) Use TRACE logging instead of
DEBUG for the absolute nitty-gritties
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12454566 ]
Oleg Kalnichevski commented on HTTPCLIENT-609:
----------------------------------------------
Abandoned may be too strong a word. The point is further improvement of HttpClient is simply not feasible without fundamental changes in the core components (see [1]). HttpClient 3.x line will be supported until HttpClient 4.x is ready and well tested. This said, anyone how wants new features / non-critical fixes in HttpClient 3.x must be prepared to 'scratch his/her own itch'
Oleg
[1] http://jakarta.apache.org/httpcomponents/commons-httpclient-lessons.html
> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
> Key: HTTPCLIENT-609
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Affects Versions: 3.1 Beta 1
> Environment: n/a
> Reporter: Endre Stølsvik
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
> * httpclient.wire.*
> * org.apache.commons.httpclient.params.DefaultHttpParams
> * org.apache.commons.httpclient.HttpMethodBase
> * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information.
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org