Re: Log misleading for User-Agent
Hi Oleg and All:
I've added in core:
org.apache.http.util.VersionInfo.setUserAgent(HttpParams, String,
String, Class?)
but it is not quite right yet: The code needs adjusting to account for the
deprecated types in 4.3 {@link HttpParams} and {@link HttpProtocolParams}.
How can this be adjusted? I take the adjustment needs to wait for Oleg's
refectoring with the new config code?
Thank you,
Gary
On Sun, Nov 18, 2012 at 3:05 PM, Gary Gregory garydgreg...@gmail.comwrote:
On Nov 18, 2012, at 14:31, Oleg Kalnichevski ol...@apache.org wrote:
On Sun, 2012-11-18 at 10:35 -0500, Gary Gregory wrote:
...
I was just thinking that the client was the right place given the
snippet in question clearly had HttpClient specific bits.
Anyway, feel free to put that code in a place you deem most
appropriate.
There is now o.a.h.config package in core for configuration components.
o.a.h.utils might be another place.
Hi Oleg,
I'm not sure how this would work in the o.a.h.config context. I can add
new
Utils class in o.a.h.utils but how would that be better or different
than
the deprecated HttpProtocolParams?
Thank you for your guidance,
Gary
Hi Gary
Unless I am missing something really fundamental here, adding this code
to a deprecated class would also make it deprecated. Unless you intend
to un-deprecate HttpProtocolParams would not a new class make more
sense?
Yes and a I'll add a new class then.
Gary
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Log misleading for User-Agent
On Sat, Nov 17, 2012 at 4:54 PM, Oleg Kalnichevski ol...@apache.org wrote:
On Sat, 2012-11-17 at 12:49 -0500, Gary Gregory wrote:
On Sat, Nov 17, 2012 at 10:25 AM, Oleg Kalnichevski ol...@apache.org
wrote:
On Fri, 2012-11-16 at 21:19 -0500, Gary Gregory wrote:
As a tangent I want to reduce this code pattern which is duplicated
no
less
than six times:
// determine the release version from packaged version info
final VersionInfo vi = VersionInfo.loadVersionInfo
(org.apache.http.client,
HttpClientBuilder.class.getClassLoader());
final String release = (vi != null) ?
vi.getRelease() : VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params,
Apache-HttpClient/ + release + (java 1.5));
into a new method:
setUserAgent(params, Apache-HttpClient,
org.apache.http.client,
HttpClientBuilder.class);
public static void setUserAgent(HttpParams params, String name,
String
pkg, Class? cls) {
final VersionInfo vi = VersionInfo.loadVersionInfo(pkg,
cls.getClassLoader());
final String release = (vi != null) ? vi.getRelease() :
VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params, name + / + release
+
(java 1.5));
}
The question is: where in Core should it go?
I see that HttpProtocolParams is deprecated, so it cannot go in
there.
So... where?
Gary
Gary
HttpClient trunk is in a state of flux right now. But please bear with
me a little while longer. I think HttpCore 4.3-alpha1 should be ready
quite soon. Once HttpClient trunk picks up new APIs from HttpCore 4.3 a
lot of things should become clearer (or so I would like to hope).
---
I think this particular bit belongs to HttpClientBuilder and it should
only be used once. Another place for it might be HttpClientUtils.
But neither of these classes are in the Core. The 3 (not 6) code
duplications are in both the regular and async clients such that the core
is the only place to put it to avoid duplication. Am I missing something?
-
org.apache.http.impl.nio.client.DefaultHttpAsyncClient.setDefaultHttpParams(HttpParams)
-
org.apache.http.impl.client.builder.HttpClientBuilder.setUserAgent(HttpParams,
String, String, Class?)
-
org.apache.http.impl.client.DefaultHttpClient.setDefaultHttpParams(HttpParams)
I was just thinking that the client was the right place given the
snippet in question clearly had HttpClient specific bits.
Anyway, feel free to put that code in a place you deem most appropriate.
There is now o.a.h.config package in core for configuration components.
o.a.h.utils might be another place.
Hi Oleg,
I'm not sure how this would work in the o.a.h.config context. I can add new
Utils class in o.a.h.utils but how would that be better or different than
the deprecated HttpProtocolParams?
Thank you for your guidance,
Gary
I am also in favor of option 3. Besides, we might even have something
that combine option 2 and 3
3) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5 compatible;
Java/1.6.0_35)
Hm... but HttpClient is also compatible with Java 1.6, that's why I
considered the minimum verbiage:
3) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5 minimum; Java/1.6.0_35)
Fair enough. Makes sense.
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Log misleading for User-Agent
On Sun, 2012-11-18 at 10:35 -0500, Gary Gregory wrote: ... I was just thinking that the client was the right place given the snippet in question clearly had HttpClient specific bits. Anyway, feel free to put that code in a place you deem most appropriate. There is now o.a.h.config package in core for configuration components. o.a.h.utils might be another place. Hi Oleg, I'm not sure how this would work in the o.a.h.config context. I can add new Utils class in o.a.h.utils but how would that be better or different than the deprecated HttpProtocolParams? Thank you for your guidance, Gary Hi Gary Unless I am missing something really fundamental here, adding this code to a deprecated class would also make it deprecated. Unless you intend to un-deprecate HttpProtocolParams would not a new class make more sense? Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
On Nov 18, 2012, at 14:31, Oleg Kalnichevski ol...@apache.org wrote: On Sun, 2012-11-18 at 10:35 -0500, Gary Gregory wrote: ... I was just thinking that the client was the right place given the snippet in question clearly had HttpClient specific bits. Anyway, feel free to put that code in a place you deem most appropriate. There is now o.a.h.config package in core for configuration components. o.a.h.utils might be another place. Hi Oleg, I'm not sure how this would work in the o.a.h.config context. I can add new Utils class in o.a.h.utils but how would that be better or different than the deprecated HttpProtocolParams? Thank you for your guidance, Gary Hi Gary Unless I am missing something really fundamental here, adding this code to a deprecated class would also make it deprecated. Unless you intend to un-deprecate HttpProtocolParams would not a new class make more sense? Yes and a I'll add a new class then. Gary Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
On Fri, 2012-11-16 at 21:19 -0500, Gary Gregory wrote:
As a tangent I want to reduce this code pattern which is duplicated no less
than six times:
// determine the release version from packaged version info
final VersionInfo vi = VersionInfo.loadVersionInfo
(org.apache.http.client,
HttpClientBuilder.class.getClassLoader());
final String release = (vi != null) ?
vi.getRelease() : VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params,
Apache-HttpClient/ + release + (java 1.5));
into a new method:
setUserAgent(params, Apache-HttpClient, org.apache.http.client,
HttpClientBuilder.class);
public static void setUserAgent(HttpParams params, String name, String
pkg, Class? cls) {
final VersionInfo vi = VersionInfo.loadVersionInfo(pkg,
cls.getClassLoader());
final String release = (vi != null) ? vi.getRelease() :
VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params, name + / + release +
(java 1.5));
}
The question is: where in Core should it go?
I see that HttpProtocolParams is deprecated, so it cannot go in there.
So... where?
Gary
Gary
HttpClient trunk is in a state of flux right now. But please bear with
me a little while longer. I think HttpCore 4.3-alpha1 should be ready
quite soon. Once HttpClient trunk picks up new APIs from HttpCore 4.3 a
lot of things should become clearer (or so I would like to hope).
---
I think this particular bit belongs to HttpClientBuilder and it should
only be used once. Another place for it might be HttpClientUtils.
I am also in favor of option 3. Besides, we might even have something
that combine option 2 and 3
3) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5 compatible;
Java/1.6.0_35)
---
I double-checked JIRA settings once again and found out that I had had
used an older (or different) account of yours. Could you please try
again and let me know of the name of the account you have been using if
it still does not work?
Oleg
On Fri, Nov 16, 2012 at 9:12 PM, Jon Moore j...@apache.org wrote:
On Fri, Nov 16, 2012 at 8:42 PM, Gary Gregory garydgreg...@gmail.com
wrote:
1) do nothing
2) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5+ min)
3) User-Agent: Apache-HttpClient/4.2.1 (Java/1.6.0_35)
3 is in the spirit of the JRE's HttpURLConnection FWIW.
If you're collecting votes, I'd vote for #3, but I have no objections
to any of these--all are reasonable.
Jon
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
On Sat, Nov 17, 2012 at 10:25 AM, Oleg Kalnichevski ol...@apache.orgwrote:
On Fri, 2012-11-16 at 21:19 -0500, Gary Gregory wrote:
As a tangent I want to reduce this code pattern which is duplicated no
less
than six times:
// determine the release version from packaged version info
final VersionInfo vi = VersionInfo.loadVersionInfo
(org.apache.http.client,
HttpClientBuilder.class.getClassLoader());
final String release = (vi != null) ?
vi.getRelease() : VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params,
Apache-HttpClient/ + release + (java 1.5));
into a new method:
setUserAgent(params, Apache-HttpClient, org.apache.http.client,
HttpClientBuilder.class);
public static void setUserAgent(HttpParams params, String name,
String
pkg, Class? cls) {
final VersionInfo vi = VersionInfo.loadVersionInfo(pkg,
cls.getClassLoader());
final String release = (vi != null) ? vi.getRelease() :
VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params, name + / + release +
(java 1.5));
}
The question is: where in Core should it go?
I see that HttpProtocolParams is deprecated, so it cannot go in there.
So... where?
Gary
Gary
HttpClient trunk is in a state of flux right now. But please bear with
me a little while longer. I think HttpCore 4.3-alpha1 should be ready
quite soon. Once HttpClient trunk picks up new APIs from HttpCore 4.3 a
lot of things should become clearer (or so I would like to hope).
---
I think this particular bit belongs to HttpClientBuilder and it should
only be used once. Another place for it might be HttpClientUtils.
But neither of these classes are in the Core. The 3 (not 6) code
duplications are in both the regular and async clients such that the core
is the only place to put it to avoid duplication. Am I missing something?
-
org.apache.http.impl.nio.client.DefaultHttpAsyncClient.setDefaultHttpParams(HttpParams)
-
org.apache.http.impl.client.builder.HttpClientBuilder.setUserAgent(HttpParams,
String, String, Class?)
-
org.apache.http.impl.client.DefaultHttpClient.setDefaultHttpParams(HttpParams)
I am also in favor of option 3. Besides, we might even have something
that combine option 2 and 3
3) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5 compatible;
Java/1.6.0_35)
Hm... but HttpClient is also compatible with Java 1.6, that's why I
considered the minimum verbiage:
3) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5 minimum; Java/1.6.0_35)
Gary
---
I double-checked JIRA settings once again and found out that I had had
used an older (or different) account of yours. Could you please try
again and let me know of the name of the account you have been using if
it still does not work?
My account is all set now, thank you. I marked
HTTPCLIENT-1260https://issues.apache.org/jira/browse/HTTPCLIENT-1260as
resolved for 4.3-aplpha1. I'll have to find a way to get rid of my old
account to avoid further confusion.
Gary
Oleg
On Fri, Nov 16, 2012 at 9:12 PM, Jon Moore j...@apache.org wrote:
On Fri, Nov 16, 2012 at 8:42 PM, Gary Gregory garydgreg...@gmail.com
wrote:
1) do nothing
2) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5+ min)
3) User-Agent: Apache-HttpClient/4.2.1 (Java/1.6.0_35)
3 is in the spirit of the JRE's HttpURLConnection FWIW.
If you're collecting votes, I'd vote for #3, but I have no objections
to any of these--all are reasonable.
Jon
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Log misleading for User-Agent
On Sat, 2012-11-17 at 12:49 -0500, Gary Gregory wrote:
On Sat, Nov 17, 2012 at 10:25 AM, Oleg Kalnichevski ol...@apache.orgwrote:
On Fri, 2012-11-16 at 21:19 -0500, Gary Gregory wrote:
As a tangent I want to reduce this code pattern which is duplicated no
less
than six times:
// determine the release version from packaged version info
final VersionInfo vi = VersionInfo.loadVersionInfo
(org.apache.http.client,
HttpClientBuilder.class.getClassLoader());
final String release = (vi != null) ?
vi.getRelease() : VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params,
Apache-HttpClient/ + release + (java 1.5));
into a new method:
setUserAgent(params, Apache-HttpClient, org.apache.http.client,
HttpClientBuilder.class);
public static void setUserAgent(HttpParams params, String name,
String
pkg, Class? cls) {
final VersionInfo vi = VersionInfo.loadVersionInfo(pkg,
cls.getClassLoader());
final String release = (vi != null) ? vi.getRelease() :
VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params, name + / + release +
(java 1.5));
}
The question is: where in Core should it go?
I see that HttpProtocolParams is deprecated, so it cannot go in there.
So... where?
Gary
Gary
HttpClient trunk is in a state of flux right now. But please bear with
me a little while longer. I think HttpCore 4.3-alpha1 should be ready
quite soon. Once HttpClient trunk picks up new APIs from HttpCore 4.3 a
lot of things should become clearer (or so I would like to hope).
---
I think this particular bit belongs to HttpClientBuilder and it should
only be used once. Another place for it might be HttpClientUtils.
But neither of these classes are in the Core. The 3 (not 6) code
duplications are in both the regular and async clients such that the core
is the only place to put it to avoid duplication. Am I missing something?
-
org.apache.http.impl.nio.client.DefaultHttpAsyncClient.setDefaultHttpParams(HttpParams)
-
org.apache.http.impl.client.builder.HttpClientBuilder.setUserAgent(HttpParams,
String, String, Class?)
-
org.apache.http.impl.client.DefaultHttpClient.setDefaultHttpParams(HttpParams)
I was just thinking that the client was the right place given the
snippet in question clearly had HttpClient specific bits.
Anyway, feel free to put that code in a place you deem most appropriate.
There is now o.a.h.config package in core for configuration components.
o.a.h.utils might be another place.
I am also in favor of option 3. Besides, we might even have something
that combine option 2 and 3
3) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5 compatible;
Java/1.6.0_35)
Hm... but HttpClient is also compatible with Java 1.6, that's why I
considered the minimum verbiage:
3) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5 minimum; Java/1.6.0_35)
Fair enough. Makes sense.
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
Yes, I'd be in favor of either one of these changes (removing or reporting dynamically the right version). I'd probably lean towards removing it if pressed to express an opinion. As I recall (although I don't have the code in front of me), the CachingHttpClient sends a slightly different User-Agent, mentioning the fact that the cache is present in the stack in the comment field. I think this made sense originally, when it was really an add-on module. However, since Oleg is re-wiring the stack for the default client in 4.3, that may not be needed any more. It could just be that I'm remembering the comment in the Via header the caching layer adds, though; in which case the caching client wouldn't modify the User-Agent. Jon On Thu, Nov 15, 2012 at 9:00 PM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: At the debug logging level I see: User-Agent: Apache-HttpClient/4.2.1 (java 1.5) But I am running on Java 6... so, Why is 1.5 hard coded? Could/Should we remove (java 1.5) or have it report the correct version? Thoughts? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
On Fri, 2012-11-16 at 06:38 -0500, Jon Moore wrote: Yes, I'd be in favor of either one of these changes (removing or reporting dynamically the right version). I'd probably lean towards removing it if pressed to express an opinion. As I recall (although I don't have the code in front of me), the CachingHttpClient sends a slightly different User-Agent, mentioning the fact that the cache is present in the stack in the comment field. I think this made sense originally, when it was really an add-on module. However, since Oleg is re-wiring the stack for the default client in 4.3, that may not be needed any more. It could just be that I'm remembering the comment in the Via header the caching layer adds, though; in which case the caching client wouldn't modify the User-Agent. Jon On Thu, Nov 15, 2012 at 9:00 PM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: At the debug logging level I see: User-Agent: Apache-HttpClient/4.2.1 (java 1.5) But I am running on Java 6... so, Why is 1.5 hard coded? Could/Should we remove (java 1.5) or have it report the correct version? Thoughts? Gary If my memory serves me well the original intention was to include a minimal JRE version a particular release is compatible with. I am fine with either dropping it or replacing with a dynamically generated JRE version requests are generated with. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
On 16 November 2012 15:55, Oleg Kalnichevski ol...@apache.org wrote: On Fri, 2012-11-16 at 06:38 -0500, Jon Moore wrote: Yes, I'd be in favor of either one of these changes (removing or reporting dynamically the right version). I'd probably lean towards removing it if pressed to express an opinion. As I recall (although I don't have the code in front of me), the CachingHttpClient sends a slightly different User-Agent, mentioning the fact that the cache is present in the stack in the comment field. I think this made sense originally, when it was really an add-on module. However, since Oleg is re-wiring the stack for the default client in 4.3, that may not be needed any more. It could just be that I'm remembering the comment in the Via header the caching layer adds, though; in which case the caching client wouldn't modify the User-Agent. Jon On Thu, Nov 15, 2012 at 9:00 PM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: At the debug logging level I see: User-Agent: Apache-HttpClient/4.2.1 (java 1.5) But I am running on Java 6... so, Why is 1.5 hard coded? Could/Should we remove (java 1.5) or have it report the correct version? Thoughts? Gary If my memory serves me well the original intention was to include a minimal JRE version a particular release is compatible with. I am fine with either dropping it or replacing with a dynamically generated JRE version requests are generated with. Or replace with: User-Agent: Apache-HttpClient/4.2.1 (Java 1.5+) if we want to keep the original meaning (but clarify it). Do other user agents include OS/Java details in their UA strings? Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
On Fri, 2012-11-16 at 17:33 +, sebb wrote: On 16 November 2012 15:55, Oleg Kalnichevski ol...@apache.org wrote: On Fri, 2012-11-16 at 06:38 -0500, Jon Moore wrote: Yes, I'd be in favor of either one of these changes (removing or reporting dynamically the right version). I'd probably lean towards removing it if pressed to express an opinion. As I recall (although I don't have the code in front of me), the CachingHttpClient sends a slightly different User-Agent, mentioning the fact that the cache is present in the stack in the comment field. I think this made sense originally, when it was really an add-on module. However, since Oleg is re-wiring the stack for the default client in 4.3, that may not be needed any more. It could just be that I'm remembering the comment in the Via header the caching layer adds, though; in which case the caching client wouldn't modify the User-Agent. Jon On Thu, Nov 15, 2012 at 9:00 PM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: At the debug logging level I see: User-Agent: Apache-HttpClient/4.2.1 (java 1.5) But I am running on Java 6... so, Why is 1.5 hard coded? Could/Should we remove (java 1.5) or have it report the correct version? Thoughts? Gary If my memory serves me well the original intention was to include a minimal JRE version a particular release is compatible with. I am fine with either dropping it or replacing with a dynamically generated JRE version requests are generated with. Or replace with: User-Agent: Apache-HttpClient/4.2.1 (Java 1.5+) if we want to keep the original meaning (but clarify it). Sounds very reasonable. Do other user agents include OS/Java details in their UA strings? I believe JRE's internal HTTP client does. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
On Fri, Nov 16, 2012 at 8:42 PM, Gary Gregory garydgreg...@gmail.com wrote: 1) do nothing 2) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5+ min) 3) User-Agent: Apache-HttpClient/4.2.1 (Java/1.6.0_35) 3 is in the spirit of the JRE's HttpURLConnection FWIW. If you're collecting votes, I'd vote for #3, but I have no objections to any of these--all are reasonable. Jon - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Log misleading for User-Agent
As a tangent I want to reduce this code pattern which is duplicated no less
than six times:
// determine the release version from packaged version info
final VersionInfo vi = VersionInfo.loadVersionInfo
(org.apache.http.client,
HttpClientBuilder.class.getClassLoader());
final String release = (vi != null) ?
vi.getRelease() : VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params,
Apache-HttpClient/ + release + (java 1.5));
into a new method:
setUserAgent(params, Apache-HttpClient, org.apache.http.client,
HttpClientBuilder.class);
public static void setUserAgent(HttpParams params, String name, String
pkg, Class? cls) {
final VersionInfo vi = VersionInfo.loadVersionInfo(pkg,
cls.getClassLoader());
final String release = (vi != null) ? vi.getRelease() :
VersionInfo.UNAVAILABLE;
HttpProtocolParams.setUserAgent(params, name + / + release +
(java 1.5));
}
The question is: where in Core should it go?
I see that HttpProtocolParams is deprecated, so it cannot go in there.
So... where?
Gary
On Fri, Nov 16, 2012 at 9:12 PM, Jon Moore j...@apache.org wrote:
On Fri, Nov 16, 2012 at 8:42 PM, Gary Gregory garydgreg...@gmail.com
wrote:
1) do nothing
2) User-Agent: Apache-HttpClient/4.2.1 (Java 1.5+ min)
3) User-Agent: Apache-HttpClient/4.2.1 (Java/1.6.0_35)
3 is in the spirit of the JRE's HttpURLConnection FWIW.
If you're collecting votes, I'd vote for #3, but I have no objections
to any of these--all are reasonable.
Jon
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
