[jira] Created: (HTTPCLIENT-805) Pass ClientConnectionManager to DefaultHttpClient constructor

Pass ClientConnectionManager to DefaultHttpClient constructor
-------------------------------------------------------------

                 Key: HTTPCLIENT-805
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
             Project: HttpComponents HttpClient
          Issue Type: Improvement
          Components: HttpClient, HttpConn
    Affects Versions: 4.0 Beta 1
            Reporter: Kenny MacLeod


Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.

I'm trying to find the least verbose way of configuring a
DefaultHttpClient with a ThreadSafeClientConnManager.

The example code given for this goes through a manual process of
configuring HttpParams and SchemeRegistry objects, which is more or less
copied from the DefaultHttpClient.createHttpParams() and
createClientConnectionManager() methods.

It's a bit of a chicken and egg situation - DefaultHttpClient can create
its own HttpParams and SchemeRegistry, which are themselves fine, but
only once its been constructed, and the constructor requires the
ThreadSafeClientConnManager, but that in turn requires the HttpParams
and SchemeRegistry objects.  The only way out is to manually construct
the HttpParams and SchemeRegistry, which is a waste.

It seems to me that DefaultHttpClient's constructor should take a
ClientConnectionManagerFactory instead of a ClientConnectionManager.
That way, the createClientConnectionManager() method already has the
factory reference, and doesn't have to grub around in the HttpParams
object to find it.

The code would then become:

new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);

where ThreadSafeClientConnManagerFactory.newInstance() just constructs
ThreadSafeClientConnManager.  There's no manual construction of
HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.


--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kenny MacLeod updated HTTPCLIENT-805:
-------------------------------------

    Description:
Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.

I'm trying to find the least verbose way of configuring a DefaultHttpClient with a ThreadSafeClientConnManager.

The example code given for this goes through a manual process of configuring HttpParams and SchemeRegistry objects, which is more or less copied from the DefaultHttpClient.createHttpParams() and createClientConnectionManager() methods.

It's a bit of a chicken and egg situation - DefaultHttpClient can create its own HttpParams and SchemeRegistry, which are themselves fine, but only once its been constructed, and the constructor requires the ThreadSafeClientConnManager, but that in turn requires the HttpParams and SchemeRegistry objects.  The only way out is to manually construct the HttpParams and SchemeRegistry, which is a waste.

It seems to me that DefaultHttpClient's constructor should take a ClientConnectionManagerFactory instead of a ClientConnectionManager. That way, the createClientConnectionManager() method already has the factory reference, and doesn't have to grub around in the HttpParams object to find it.

The code would then become:

new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);

where ThreadSafeClientConnManagerFactory.newInstance() just constructs ThreadSafeClientConnManager.  There's no manual construction of HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.


  was:
Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.

I'm trying to find the least verbose way of configuring a
DefaultHttpClient with a ThreadSafeClientConnManager.

The example code given for this goes through a manual process of
configuring HttpParams and SchemeRegistry objects, which is more or less
copied from the DefaultHttpClient.createHttpParams() and
createClientConnectionManager() methods.

It's a bit of a chicken and egg situation - DefaultHttpClient can create
its own HttpParams and SchemeRegistry, which are themselves fine, but
only once its been constructed, and the constructor requires the
ThreadSafeClientConnManager, but that in turn requires the HttpParams
and SchemeRegistry objects.  The only way out is to manually construct
the HttpParams and SchemeRegistry, which is a waste.

It seems to me that DefaultHttpClient's constructor should take a
ClientConnectionManagerFactory instead of a ClientConnectionManager.
That way, the createClientConnectionManager() method already has the
factory reference, and doesn't have to grub around in the HttpParams
object to find it.

The code would then become:

new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);

where ThreadSafeClientConnManagerFactory.newInstance() just constructs
ThreadSafeClientConnManager.  There's no manual construction of
HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.

> Pass ClientConnectionManager to DefaultHttpClient constructor
> -------------------------------------------------------------
>
>                 Key: HTTPCLIENT-805
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient, HttpConn
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kenny MacLeod
>
> Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.
> I'm trying to find the least verbose way of configuring a DefaultHttpClient with a ThreadSafeClientConnManager.
> The example code given for this goes through a manual process of configuring HttpParams and SchemeRegistry objects, which is more or less copied from the DefaultHttpClient.createHttpParams() and createClientConnectionManager() methods.
> It's a bit of a chicken and egg situation - DefaultHttpClient can create its own HttpParams and SchemeRegistry, which are themselves fine, but only once its been constructed, and the constructor requires the ThreadSafeClientConnManager, but that in turn requires the HttpParams and SchemeRegistry objects.  The only way out is to manually construct the HttpParams and SchemeRegistry, which is a waste.
> It seems to me that DefaultHttpClient's constructor should take a ClientConnectionManagerFactory instead of a ClientConnectionManager. That way, the createClientConnectionManager() method already has the factory reference, and doesn't have to grub around in the HttpParams object to find it.
> The code would then become:
> new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);
> where ThreadSafeClientConnManagerFactory.newInstance() just constructs ThreadSafeClientConnManager.  There's no manual construction of HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski updated HTTPCLIENT-805:
-----------------------------------------

    Fix Version/s: 4.1.0

> Pass ClientConnectionManager to DefaultHttpClient constructor
> -------------------------------------------------------------
>
>                 Key: HTTPCLIENT-805
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient, HttpConn
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kenny MacLeod
>             Fix For: 4.1.0
>
>
> Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.
> I'm trying to find the least verbose way of configuring a DefaultHttpClient with a ThreadSafeClientConnManager.
> The example code given for this goes through a manual process of configuring HttpParams and SchemeRegistry objects, which is more or less copied from the DefaultHttpClient.createHttpParams() and createClientConnectionManager() methods.
> It's a bit of a chicken and egg situation - DefaultHttpClient can create its own HttpParams and SchemeRegistry, which are themselves fine, but only once its been constructed, and the constructor requires the ThreadSafeClientConnManager, but that in turn requires the HttpParams and SchemeRegistry objects.  The only way out is to manually construct the HttpParams and SchemeRegistry, which is a waste.
> It seems to me that DefaultHttpClient's constructor should take a ClientConnectionManagerFactory instead of a ClientConnectionManager. That way, the createClientConnectionManager() method already has the factory reference, and doesn't have to grub around in the HttpParams object to find it.
> The code would then become:
> new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);
> where ThreadSafeClientConnManagerFactory.newInstance() just constructs ThreadSafeClientConnManager.  There's no manual construction of HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

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

Sean Sullivan commented on HTTPCLIENT-805:
------------------------------------------


Are there any plans to resolve this in HttpClient 4.0?    (This issue has been open for 3 months and HttpClient 4.0 is still in beta)

> Pass ClientConnectionManager to DefaultHttpClient constructor
> -------------------------------------------------------------
>
>                 Key: HTTPCLIENT-805
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient, HttpConn
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kenny MacLeod
>             Fix For: 4.1.0
>
>
> Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.
> I'm trying to find the least verbose way of configuring a DefaultHttpClient with a ThreadSafeClientConnManager.
> The example code given for this goes through a manual process of configuring HttpParams and SchemeRegistry objects, which is more or less copied from the DefaultHttpClient.createHttpParams() and createClientConnectionManager() methods.
> It's a bit of a chicken and egg situation - DefaultHttpClient can create its own HttpParams and SchemeRegistry, which are themselves fine, but only once its been constructed, and the constructor requires the ThreadSafeClientConnManager, but that in turn requires the HttpParams and SchemeRegistry objects.  The only way out is to manually construct the HttpParams and SchemeRegistry, which is a waste.
> It seems to me that DefaultHttpClient's constructor should take a ClientConnectionManagerFactory instead of a ClientConnectionManager. That way, the createClientConnectionManager() method already has the factory reference, and doesn't have to grub around in the HttpParams object to find it.
> The code would then become:
> new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);
> where ThreadSafeClientConnManagerFactory.newInstance() just constructs ThreadSafeClientConnManager.  There's no manual construction of HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

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

Oleg Kalnichevski commented on HTTPCLIENT-805:
----------------------------------------------

No, no such plans, unless we are willing to sacrifice complete binary compatibility with the version shipped with Google Android.

Oleg

> Pass ClientConnectionManager to DefaultHttpClient constructor
> -------------------------------------------------------------
>
>                 Key: HTTPCLIENT-805
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient, HttpConn
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kenny MacLeod
>             Fix For: 4.1.0
>
>
> Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.
> I'm trying to find the least verbose way of configuring a DefaultHttpClient with a ThreadSafeClientConnManager.
> The example code given for this goes through a manual process of configuring HttpParams and SchemeRegistry objects, which is more or less copied from the DefaultHttpClient.createHttpParams() and createClientConnectionManager() methods.
> It's a bit of a chicken and egg situation - DefaultHttpClient can create its own HttpParams and SchemeRegistry, which are themselves fine, but only once its been constructed, and the constructor requires the ThreadSafeClientConnManager, but that in turn requires the HttpParams and SchemeRegistry objects.  The only way out is to manually construct the HttpParams and SchemeRegistry, which is a waste.
> It seems to me that DefaultHttpClient's constructor should take a ClientConnectionManagerFactory instead of a ClientConnectionManager. That way, the createClientConnectionManager() method already has the factory reference, and doesn't have to grub around in the HttpParams object to find it.
> The code would then become:
> new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);
> where ThreadSafeClientConnManagerFactory.newInstance() just constructs ThreadSafeClientConnManager.  There's no manual construction of HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

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

Oleg Kalnichevski commented on HTTPCLIENT-805:
----------------------------------------------

Kenny, Sean

HttpClient 4.1-snapshot now has a much simpler API for creating and configuring connection managers. HTTP parameters are no longer required when creating standard connection managers and the whole initialization process has become simpler:
---
ThreadSafeClientConnManager cm = new ThreadSafeClientConnManager(schemeRegistry);
// Increase max total connection to 200
cm.setMaxTotalConnections(200);
// Increase default max connection per route to 20
cm.setDefaultMaxPerRoute(20);
// Increase max connections for localhost:80 to 50
HttpHost localhost = new HttpHost("locahost", 80);
cm.setMaxForRoute(new HttpRoute(localhost), 50);
 
HttpClient httpClient = new DefaultHttpClient(cm);
---

One would still need to create an instance of SchemeRegistry in order to create a connection manager. Could you leave with the new approach?

I can also provide a constructor that takes ThreadSafeClientConnManagerFactory, if necessary, but that would lead to a certain ugliness in code mainly because damn Java insists on super constructor being the first call in an overloaded constructor.

Please take a look at the new API and let me know if it is okay to close the issue as FIXED.

Oleg

> Pass ClientConnectionManager to DefaultHttpClient constructor
> -------------------------------------------------------------
>
>                 Key: HTTPCLIENT-805
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient, HttpConn
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kenny MacLeod
>             Fix For: 4.1.0
>
>
> Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.
> I'm trying to find the least verbose way of configuring a DefaultHttpClient with a ThreadSafeClientConnManager.
> The example code given for this goes through a manual process of configuring HttpParams and SchemeRegistry objects, which is more or less copied from the DefaultHttpClient.createHttpParams() and createClientConnectionManager() methods.
> It's a bit of a chicken and egg situation - DefaultHttpClient can create its own HttpParams and SchemeRegistry, which are themselves fine, but only once its been constructed, and the constructor requires the ThreadSafeClientConnManager, but that in turn requires the HttpParams and SchemeRegistry objects.  The only way out is to manually construct the HttpParams and SchemeRegistry, which is a waste.
> It seems to me that DefaultHttpClient's constructor should take a ClientConnectionManagerFactory instead of a ClientConnectionManager. That way, the createClientConnectionManager() method already has the factory reference, and doesn't have to grub around in the HttpParams object to find it.
> The code would then become:
> new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);
> where ThreadSafeClientConnManagerFactory.newInstance() just constructs ThreadSafeClientConnManager.  There's no manual construction of HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-805.
------------------------------------------

    Resolution: Fixed

> Pass ClientConnectionManager to DefaultHttpClient constructor
> -------------------------------------------------------------
>
>                 Key: HTTPCLIENT-805
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient, HttpConn
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kenny MacLeod
>             Fix For: 4.1.0
>
>
> Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.
> I'm trying to find the least verbose way of configuring a DefaultHttpClient with a ThreadSafeClientConnManager.
> The example code given for this goes through a manual process of configuring HttpParams and SchemeRegistry objects, which is more or less copied from the DefaultHttpClient.createHttpParams() and createClientConnectionManager() methods.
> It's a bit of a chicken and egg situation - DefaultHttpClient can create its own HttpParams and SchemeRegistry, which are themselves fine, but only once its been constructed, and the constructor requires the ThreadSafeClientConnManager, but that in turn requires the HttpParams and SchemeRegistry objects.  The only way out is to manually construct the HttpParams and SchemeRegistry, which is a waste.
> It seems to me that DefaultHttpClient's constructor should take a ClientConnectionManagerFactory instead of a ClientConnectionManager. That way, the createClientConnectionManager() method already has the factory reference, and doesn't have to grub around in the HttpParams object to find it.
> The code would then become:
> new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);
> where ThreadSafeClientConnManagerFactory.newInstance() just constructs ThreadSafeClientConnManager.  There's no manual construction of HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

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

Ismael Juma commented on HTTPCLIENT-805:
----------------------------------------

I think this would be better if one could get a default scheme registry from somewhere. By default I mean one like the one created in DefaultHttpClient.createClientConnectionManager:

        SchemeRegistry registry = new SchemeRegistry();
        registry.register(
                new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
        registry.register(
                new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));

> Pass ClientConnectionManager to DefaultHttpClient constructor
> -------------------------------------------------------------
>
>                 Key: HTTPCLIENT-805
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-805
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient, HttpConn
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kenny MacLeod
>             Fix For: 4.1 Alpha1
>
>
> Copied from my mailing list post, Oleg suggested I post it to JIRA for 4.1 fix.
> I'm trying to find the least verbose way of configuring a DefaultHttpClient with a ThreadSafeClientConnManager.
> The example code given for this goes through a manual process of configuring HttpParams and SchemeRegistry objects, which is more or less copied from the DefaultHttpClient.createHttpParams() and createClientConnectionManager() methods.
> It's a bit of a chicken and egg situation - DefaultHttpClient can create its own HttpParams and SchemeRegistry, which are themselves fine, but only once its been constructed, and the constructor requires the ThreadSafeClientConnManager, but that in turn requires the HttpParams and SchemeRegistry objects.  The only way out is to manually construct the HttpParams and SchemeRegistry, which is a waste.
> It seems to me that DefaultHttpClient's constructor should take a ClientConnectionManagerFactory instead of a ClientConnectionManager. That way, the createClientConnectionManager() method already has the factory reference, and doesn't have to grub around in the HttpParams object to find it.
> The code would then become:
> new DefaultHttpClient(new ThreadSafeClientConnManagerFactory(), null);
> where ThreadSafeClientConnManagerFactory.newInstance() just constructs ThreadSafeClientConnManager.  There's no manual construction of HttpParams and SchemeRegistry, you just leave it up to DefaultHttpClient.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...