[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962364#comment-14962364
 ] 

Oleg Kalnichevski commented on HTTPCLIENT-1691:
-----------------------------------------------

Andrew, 
The decision to avoid the use of any system properties by default was a 
conscious design decision made over a decade ago in the days of HC 2.x when 
literally everything was expected to be run inside a J2EE container with 
restricted access to system properties. While the original assumption no longer 
holds true and should be reconsidered in 5.x, it is quite trivial to make 
HttpClient (and HC fluent) respect system properties if so desired.

{code:java}
Executor executor = Executor.newInstance(HttpClients.createSystem());
executor.execute(Request.Get("/")).discardContent();
{code}

Oleg

> Wouldn't it be better if the Fluent Executor set useSystemProperties on its 
> HttpClient?
> ---------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1691
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1691
>             Project: HttpComponents HttpClient
>          Issue Type: Wish
>          Components: Fluent HC
>    Affects Versions: 4.5
>            Reporter: Andrew Garrett
>            Priority: Minor
>             Fix For: 5.0
>
>
> Is the fact that the Fluent Executor does not call useSystemProperties when 
> building its HttpClient a design decision? This is quite painful as it 
> requires us to fork a library we are using, which in turn uses the Fluent 
> client, in order to get it to accept proxy settings by manually adding the 
> proxy. Every other library that our application uses respects http.proxyHost 
> and http.proxyPort, so this is pretty unfortunate. If not using the system 
> properties was not a design decision, can we change the Fluent Executor to 
> use them?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to