Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-563

Provide support for Apache HttpClient 4.0

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 2.1 RC1
    • Component/s: Core
    • Labels:
      None

      Description

      I would like to be able to use the Apache HttpClient 4.0 in Spring WS, now that it is out of beta

      1. HttpClientConnection.java
        6 kB
        Barry
      2. HttpClientConnection.java
        4 kB
        Alan Stewart (personal account)
      3. HttpClientMessageSender.java
        9 kB
        Barry
      4. HttpClientMessageSender.java
        8 kB
        Alan Stewart (personal account)
      5. HttpClientMessageSender.java
        8 kB
        Alan Stewart (personal account)
      6. ProtocolExceptionOverrideInterceptor.java
        2 kB
        Barry

        Activity

        alankstewart Alan Stewart (personal account) created issue -
        arjen.poutsma Arjen Poutsma made changes -
        Field Original Value New Value
        Fix Version/s 2.0 [ 10981 ]
        Hide
        olegk Oleg Kalnichevski added a comment -

        I am willing to give a helping hand with that.

        Oleg (Apache HttpComponents committer)

        Show
        olegk Oleg Kalnichevski added a comment - I am willing to give a helping hand with that. Oleg (Apache HttpComponents committer)
        alankstewart Alan Stewart (personal account) made changes -
        Attachment HttpClientMessageSender.java [ 15706 ]
        Hide
        alankstewart Alan Stewart (personal account) added a comment -

        Oleg - that's great! I mentioned in the forum entry that I would have a go at it. I created a class called HttpClientMessageSender (a copy of the CommonHttpMessageSender class) that also extends org.springframework.ws.transport.http.AbstractHttpWebServiceMessageSender . I converted most of the methods but there seems to be in some cases no direct equivalent from Commons to the new client. I got stuck on the setMaxConnectionsPerHost method. It may not be relevant anymore anyway but with your expertise in this, it should be quite trivial. An implementation of the org.springframework.ws.transport .WebServiceConnection is also required as well.
        Thanks
        Alan

        Show
        alankstewart Alan Stewart (personal account) added a comment - Oleg - that's great! I mentioned in the forum entry that I would have a go at it. I created a class called HttpClientMessageSender (a copy of the CommonHttpMessageSender class) that also extends org.springframework.ws.transport.http.AbstractHttpWebServiceMessageSender . I converted most of the methods but there seems to be in some cases no direct equivalent from Commons to the new client. I got stuck on the setMaxConnectionsPerHost method. It may not be relevant anymore anyway but with your expertise in this, it should be quite trivial. An implementation of the org.springframework.ws.transport .WebServiceConnection is also required as well. Thanks Alan
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Thanks for all the contributions everbody!

        Show
        arjen.poutsma Arjen Poutsma added a comment - Thanks for all the contributions everbody!
        Hide
        olegk Oleg Kalnichevski added a comment -

        Alan

        public HttpClientMessageSender()

        { httpClient = new DefaultHttpClient(); setConnectionTimeout(DEFAULT_CONNECTION_TIMEOUT_MILLISECONDS); setReadTimeout(DEFAULT_READ_TIMEOUT_MILLISECONDS); }

        I would strongly recommend using ThreadSafeClientConnManager instead of the one created by HttpClient per default

        http://hc.apache.org/httpcomponents-client/tutorial/html/connmgmt.html#d4e596

        > Commons to the new client. I got stuck on the setMaxConnectionsPerHost method. It may not be relevant anymore
        > anyway but with your expertise in this, it should be quite trivial

        One can use ConnPerRouteBean class to enforce max connection limit for individual HTTP routes, as described here:

        http://hc.apache.org/httpcomponents-client/tutorial/html/connmgmt.html#d4e596
        http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/conn/params/ConnPerRouteBean.html

        > An implementation of the org.springframework.ws.transport .WebServiceConnection is also required as well.

        That's where things may get tricky. In any way I'll happily help with the HttpClient specific stuff.

        Oleg

        Show
        olegk Oleg Kalnichevski added a comment - Alan — public HttpClientMessageSender() { httpClient = new DefaultHttpClient(); setConnectionTimeout(DEFAULT_CONNECTION_TIMEOUT_MILLISECONDS); setReadTimeout(DEFAULT_READ_TIMEOUT_MILLISECONDS); } — I would strongly recommend using ThreadSafeClientConnManager instead of the one created by HttpClient per default http://hc.apache.org/httpcomponents-client/tutorial/html/connmgmt.html#d4e596 > Commons to the new client. I got stuck on the setMaxConnectionsPerHost method. It may not be relevant anymore > anyway but with your expertise in this, it should be quite trivial One can use ConnPerRouteBean class to enforce max connection limit for individual HTTP routes, as described here: http://hc.apache.org/httpcomponents-client/tutorial/html/connmgmt.html#d4e596 http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/conn/params/ConnPerRouteBean.html > An implementation of the org.springframework.ws.transport .WebServiceConnection is also required as well. That's where things may get tricky. In any way I'll happily help with the HttpClient specific stuff. Oleg
        Hide
        olegk Oleg Kalnichevski added a comment -

        One more thing. This bit looks ugly:

        public void afterPropertiesSet() throws Exception {
        if (getCredentials() != null)

        { ((DefaultHttpClient) getHttpClient()).getCredentialsProvider().setCredentials(getAuthScope(), getCredentials()); // ((DefaultHttpClient) getHttpClient()).getCredentialsProvider().setAuthenticationPreemptive(true); }

        }

        There are better ways of providing auth credentials at run-time, for instance by binding a custom credentials provider to the local execution context or by using a custom protocol interceptor. For details see:

        http://hc.apache.org/httpcomponents-client/tutorial/html/authentication.html#d4e909
        http://hc.apache.org/httpcomponents-client/tutorial/html/authentication.html#d4e942

        Oleg

        Show
        olegk Oleg Kalnichevski added a comment - One more thing. This bit looks ugly: — public void afterPropertiesSet() throws Exception { if (getCredentials() != null) { ((DefaultHttpClient) getHttpClient()).getCredentialsProvider().setCredentials(getAuthScope(), getCredentials()); // ((DefaultHttpClient) getHttpClient()).getCredentialsProvider().setAuthenticationPreemptive(true); } } — There are better ways of providing auth credentials at run-time, for instance by binding a custom credentials provider to the local execution context or by using a custom protocol interceptor. For details see: http://hc.apache.org/httpcomponents-client/tutorial/html/authentication.html#d4e909 http://hc.apache.org/httpcomponents-client/tutorial/html/authentication.html#d4e942 Oleg
        Hide
        alankstewart Alan Stewart (personal account) added a comment -

        > I would strongly recommend using ThreadSafeClientConnManager instead of the one created by HttpClient per default

        I followed the same pattern as the CommonHttpMessageSender by allowing the default constructor to create a default client, and allow the user to inject a multi-threaded connection manager (like I do in my production systems) if desired. If you think this is still a bad idea, I can change it.

        >> An implementation of the org.springframework.ws.transport .WebServiceConnection is also required as well.
        >That's where things may get tricky. In any way I'll happily help with the HttpClient specific stuff.

        I created a HttpClientConnection class which extends the Spring WS framework's org.springframework.ws.transport.http.AbstractSenderConnection as does the Commons class.
        There are some abstract methods which must be implemented:
        /** Returns the HTTP status code of the response. */
        protected abstract int getResponseCode() throws IOException;

        /** Returns the HTTP status message of the response. */
        protected abstract String getResponseMessage() throws IOException;

        /** Returns the length of the response. */
        protected abstract long getResponseContentLength() throws IOException;

        /** Returns the raw, possibly compressed input stream to read the response from. */
        protected abstract InputStream getRawResponseInputStream() throws IOException;

        I can get the last 2 working by returning httpPost.getEntity().getContentLength() and httpPost.getEntity().getContent() respectively, but can't find equivalents for getResponseCode() and getResponseMessage in HttpPost or HttpEntity.

        Attached are new versions of the code
        Alan

        Show
        alankstewart Alan Stewart (personal account) added a comment - > I would strongly recommend using ThreadSafeClientConnManager instead of the one created by HttpClient per default I followed the same pattern as the CommonHttpMessageSender by allowing the default constructor to create a default client, and allow the user to inject a multi-threaded connection manager (like I do in my production systems) if desired. If you think this is still a bad idea, I can change it. >> An implementation of the org.springframework.ws.transport .WebServiceConnection is also required as well. >That's where things may get tricky. In any way I'll happily help with the HttpClient specific stuff. I created a HttpClientConnection class which extends the Spring WS framework's org.springframework.ws.transport.http.AbstractSenderConnection as does the Commons class. There are some abstract methods which must be implemented: /** Returns the HTTP status code of the response. */ protected abstract int getResponseCode() throws IOException; /** Returns the HTTP status message of the response. */ protected abstract String getResponseMessage() throws IOException; /** Returns the length of the response. */ protected abstract long getResponseContentLength() throws IOException; /** Returns the raw, possibly compressed input stream to read the response from. */ protected abstract InputStream getRawResponseInputStream() throws IOException; I can get the last 2 working by returning httpPost.getEntity().getContentLength() and httpPost.getEntity().getContent() respectively, but can't find equivalents for getResponseCode() and getResponseMessage in HttpPost or HttpEntity. Attached are new versions of the code Alan
        alankstewart Alan Stewart (personal account) made changes -
        Attachment HttpClientMessageSender.java [ 15709 ]
        Attachment HttpClientConnection.java [ 15710 ]
        Hide
        olegk Oleg Kalnichevski added a comment -

        > I followed the same pattern as the CommonHttpMessageSender by allowing the default constructor
        > to create a default client, and allow the user to inject a multi-threaded connection manager
        > (like I do in my production systems) if desired. If you think this is still a bad idea, I can change it.

        I believe (I may be wrong here, though) CommonHttpMessageSender can be used by multiple threads to execute requests concurrently. Therefore a multi-threaded connection manager should be used by default to enable proper handling of concurrent request execution.

        > I can get the last 2 working by returning httpPost.getEntity().getContentLength() and
        > httpPost.getEntity().getContent() respectively, but can't find equivalents for
        > getResponseCode() and getResponseMessage in HttpPost or HttpEntity.

        Please note some responses may have no enclosing response entity, so you should be checking for HttpResponse#getEntity being non null just in case.

        Use HttpResponse#getStatusLine()#getStatusCode() in order to obtain the response code. Use HttpResponse#getStatusLine()#getReasonPhrase() in order to obtain the response message

        Also, make sure to call HttpEntity#consumeContent() in HttpClientConnection#onClose() to ensure correct re-use of the underlying HTTP connection and deallocation of system resources.

        Last but not the least, we should eliminate in memory buffering of the request content body. For that we might have to change the subclass of HttpClientConnection from AbstractHttpSenderConnection to something else or just implement WebServiceConnection directly. In memory buffering of request content pretty much eliminates all the benefits of using HttpClient in the first place.

        Oleg

        Show
        olegk Oleg Kalnichevski added a comment - > I followed the same pattern as the CommonHttpMessageSender by allowing the default constructor > to create a default client, and allow the user to inject a multi-threaded connection manager > (like I do in my production systems) if desired. If you think this is still a bad idea, I can change it. I believe (I may be wrong here, though) CommonHttpMessageSender can be used by multiple threads to execute requests concurrently. Therefore a multi-threaded connection manager should be used by default to enable proper handling of concurrent request execution. > I can get the last 2 working by returning httpPost.getEntity().getContentLength() and > httpPost.getEntity().getContent() respectively, but can't find equivalents for > getResponseCode() and getResponseMessage in HttpPost or HttpEntity. Please note some responses may have no enclosing response entity, so you should be checking for HttpResponse#getEntity being non null just in case. Use HttpResponse#getStatusLine()#getStatusCode() in order to obtain the response code. Use HttpResponse#getStatusLine()#getReasonPhrase() in order to obtain the response message Also, make sure to call HttpEntity#consumeContent() in HttpClientConnection#onClose() to ensure correct re-use of the underlying HTTP connection and deallocation of system resources. Last but not the least, we should eliminate in memory buffering of the request content body. For that we might have to change the subclass of HttpClientConnection from AbstractHttpSenderConnection to something else or just implement WebServiceConnection directly. In memory buffering of request content pretty much eliminates all the benefits of using HttpClient in the first place. Oleg
        Hide
        alankstewart Alan Stewart (personal account) added a comment -

        > Last but not the least, we should eliminate in memory buffering of the request content body. For that we might have to change the subclass of
        > HttpClientConnection from AbstractHttpSenderConnection to something else or just implement WebServiceConnection directly. In memory buffering of request
        > content pretty much eliminates all the benefits of using HttpClient in the first place.

        To eliminate in memory buffering, do you mean to use something other than the ByteArrayEntity in the onSendAfterWrite method? The CommonsHttpConnection uses the older ByteArrayRequestEntity. What do you suggest instead?

        Alan

        Show
        alankstewart Alan Stewart (personal account) added a comment - > Last but not the least, we should eliminate in memory buffering of the request content body. For that we might have to change the subclass of > HttpClientConnection from AbstractHttpSenderConnection to something else or just implement WebServiceConnection directly. In memory buffering of request > content pretty much eliminates all the benefits of using HttpClient in the first place. To eliminate in memory buffering, do you mean to use something other than the ByteArrayEntity in the onSendAfterWrite method? The CommonsHttpConnection uses the older ByteArrayRequestEntity. What do you suggest instead? Alan
        Hide
        olegk Oleg Kalnichevski added a comment -

        Alan

        The problem is the implementation of the WebServiceConnection#send method by AbstractWebServiceConnection class [1]

        In order to utilize HttpClient content streaming capability one should provide a custom implementation of HttpEntity interface that wraps the WebServiceMessage instance instead of writing its content out to an intermediate byte array and using ByteArrayEntity. This will enable HttpClient to write out the message content directly to the socket of the underlying HTTP connection.

        The catch is AbstractWebServiceConnection can no longer be a base class for HttpClientConnection and therefore most of its functionality may need to be duplicated.

        Oleg

        [1] https://src.springframework.org/svn/spring-ws/trunk/core/src/main/java/org/springframework/ws/transport/AbstractWebServiceConnection.java

        Show
        olegk Oleg Kalnichevski added a comment - Alan The problem is the implementation of the WebServiceConnection#send method by AbstractWebServiceConnection class [1] In order to utilize HttpClient content streaming capability one should provide a custom implementation of HttpEntity interface that wraps the WebServiceMessage instance instead of writing its content out to an intermediate byte array and using ByteArrayEntity. This will enable HttpClient to write out the message content directly to the socket of the underlying HTTP connection. The catch is AbstractWebServiceConnection can no longer be a base class for HttpClientConnection and therefore most of its functionality may need to be duplicated. Oleg [1] https://src.springframework.org/svn/spring-ws/trunk/core/src/main/java/org/springframework/ws/transport/AbstractWebServiceConnection.java
        arjen.poutsma Arjen Poutsma made changes -
        Fix Version/s 2.0 M3 [ 11391 ]
        Fix Version/s 2.0 GA [ 10981 ]
        arjen.poutsma Arjen Poutsma made changes -
        Fix Version/s 2.0 M4 [ 11626 ]
        Fix Version/s 2.0 M3 [ 11391 ]
        arjen.poutsma Arjen Poutsma made changes -
        Fix Version/s 2.0 RC1 [ 11392 ]
        Fix Version/s 2.0 M4 [ 11626 ]
        arjen.poutsma Arjen Poutsma made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        To do proper justice to the new capabilities of HttpClient 4.0, we will probably have to rewrite some of the transport logic in Spring-WS. Unfortunately, I do not have time to do that before 2.0, so I am rescheduling for 2.1.

        A shame, but that's the way it is.

        Show
        arjen.poutsma Arjen Poutsma added a comment - To do proper justice to the new capabilities of HttpClient 4.0, we will probably have to rewrite some of the transport logic in Spring-WS. Unfortunately, I do not have time to do that before 2.0, so I am rescheduling for 2.1. A shame, but that's the way it is.
        arjen.poutsma Arjen Poutsma made changes -
        Fix Version/s 2.1 M1 [ 11748 ]
        Fix Version/s 2.0 RC1 [ 11392 ]
        arjen.poutsma Arjen Poutsma logged work - 10/Dec/10 1:43 AM
        • Time Spent:
          4h 43m
           
          <No comment>
        arjen.poutsma Arjen Poutsma made changes -
        Remaining Estimate 0d [ 0 ]
        Time Spent 4h 43m [ 16980 ]
        Hide
        magott Morten Andersen-Gott added a comment -

        Have a preliminary date been set for 2.1? Or for the milestone in which this will be included?

        Show
        magott Morten Andersen-Gott added a comment - Have a preliminary date been set for 2.1? Or for the milestone in which this will be included?
        Hide
        bazeusz Piotr Bazan added a comment -

        Guys,

        I needed to do this integration (httpclient 4 and spring-ws) now and faced some issues with jdk's 6 saaj and httpclient 4. It's not so much the spring issue but you have to deal with this anyway.

        The problem is the httpclient 4 is very restrictive in its RequestContent interceptor and throws ProtocolException when a Content-Length header has been set prior to calling its process method. And this is a case with a saaj's com.sun.xml.messaging.saaj.soap.MessageImpl. The class calculates a message size itself and sets a Content-Length header in saveChanges.

        Although I agree it's a transport layer responsibility to calculate it, for compatibility purposes httpclient should consider logging a warning and maybe overriding the header instead of throwing an exception. Otherwise it must be worked around by an integration code, Spring in this case.

        Piotr

        Show
        bazeusz Piotr Bazan added a comment - Guys, I needed to do this integration (httpclient 4 and spring-ws) now and faced some issues with jdk's 6 saaj and httpclient 4. It's not so much the spring issue but you have to deal with this anyway. The problem is the httpclient 4 is very restrictive in its RequestContent interceptor and throws ProtocolException when a Content-Length header has been set prior to calling its process method. And this is a case with a saaj's com.sun.xml.messaging.saaj.soap.MessageImpl. The class calculates a message size itself and sets a Content-Length header in saveChanges. Although I agree it's a transport layer responsibility to calculate it, for compatibility purposes httpclient should consider logging a warning and maybe overriding the header instead of throwing an exception. Otherwise it must be worked around by an integration code, Spring in this case. Piotr
        Hide
        barrypitman Barry added a comment -

        I also needed this feature (my application requires multiple HttpClient instances, each of which is configured with different client X509 keyStores at startup. As far as I know that can't be done with commons-httpclient but can with Apache HttpClient 4).

        I took the attachments provided by Alan and applied all of Oleg's suggestions as well as working around the problem mentioned by Piotr (with a custom 'HttpRequestInterceptor' that clears the Content-Length and Transfer-Encoding headers set by SAAJ).

        I'll attach the files to this issue in case anyone else needs this sooner rather than later. I have tested it in my test environment and its working fine.

        Show
        barrypitman Barry added a comment - I also needed this feature (my application requires multiple HttpClient instances, each of which is configured with different client X509 keyStores at startup. As far as I know that can't be done with commons-httpclient but can with Apache HttpClient 4). I took the attachments provided by Alan and applied all of Oleg's suggestions as well as working around the problem mentioned by Piotr (with a custom 'HttpRequestInterceptor' that clears the Content-Length and Transfer-Encoding headers set by SAAJ). I'll attach the files to this issue in case anyone else needs this sooner rather than later. I have tested it in my test environment and its working fine.
        Hide
        barrypitman Barry added a comment -

        Working HttpClient-based WebServiceMessageSender implementation

        Show
        barrypitman Barry added a comment - Working HttpClient-based WebServiceMessageSender implementation
        barrypitman Barry made changes -
        Attachment HttpClientMessageSender.java [ 18592 ]
        Attachment HttpClientConnection.java [ 18593 ]
        Attachment ProtocolExceptionOverrideInterceptor.java [ 18594 ]
        arjen.poutsma Arjen Poutsma made changes -
        Status In Progress [ 3 ] Open [ 1 ]
        arjen.poutsma Arjen Poutsma made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        arjen.poutsma Arjen Poutsma logged work - 08/May/12 3:02 AM
        • Time Spent:
          0.9h
           
          <No comment>
        arjen.poutsma Arjen Poutsma made changes -
        Time Spent 4h 43m [ 16980 ] 5h 37m [ 20220 ]
        Worklog Id 28642 [ 28642 ]
        arjen.poutsma Arjen Poutsma made changes -
        Resolution Complete [ 8 ]
        Status In Progress [ 3 ] Resolved [ 5 ]
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        This is now in SVN, as HttpComponentsMessageSender.

        Thanks for the patches, guys, it really made my job a lot easier!

        Show
        arjen.poutsma Arjen Poutsma added a comment - This is now in SVN, as HttpComponentsMessageSender. Thanks for the patches, guys, it really made my job a lot easier!
        Hide
        barrypitman Barry added a comment -

        Hi Arjen,

        One of my use-cases is that I need to be able to specify different HTTP Basic Auth credentials per request, based on the current user (the context). Looking at the changes at https://fisheye.springsource.org/browse/~br=trunk/spring-ws/trunk/core/src/main/java/org/springframework/ws/transport/http/HttpComponentsConnection.java?r=1981&r=1981, I don't think that will be possible, because I need to specify a org.apache.http.protocol.HttpContext when making the request.

        Oleg alluded to using the HttpContext to supply credentials earlier:

        There are better ways of providing auth credentials at run-time, for instance by binding a custom credentials provider to the local execution context or by using a custom protocol interceptor. For details see:

        http://hc.apache.org/httpcomponents-client/tutorial/html/authentication.html#d4e909
        http://hc.apache.org/httpcomponents-client/tutorial/html/authentication.html#d4e942

        The problem is that there is no way to provide a org.apache.http.protocol.HttpContext for httpClient.execute(httpPost, httpContext).

        What I have been doing in the past is subclassing HttpComponentsMessageSender to override createConnection(URI uri), creating a HttpComponentsConnection with a HttpContext instance like so:

        public abstract class BasicAuthHttpComponentsMessageSender extends HttpComponentsMessageSender {
         
            @Override
            public WebServiceConnection createConnection(URI uri) throws IOException {
                HttpPost httpPost = new HttpPost(uri);
                if (isAcceptGzipEncoding()) {
                    httpPost.addHeader(HttpTransportConstants.HEADER_ACCEPT_ENCODING, HttpTransportConstants.CONTENT_ENCODING_GZIP);
                }
         
                HttpHost targetHost = new HttpHost(uri.getHost(), uri.getPort(), uri.getScheme());
         
                ((DefaultHttpClient) getHttpClient()).getCredentialsProvider().setCredentials(
                        new AuthScope(targetHost.getHostName(), targetHost.getPort()), getCredentials());
         
         
                AuthCache authCache = new BasicAuthCache();
                BasicScheme basicAuth = new BasicScheme();
                authCache.put(targetHost, basicAuth);
         
                BasicHttpContext localContext = new BasicHttpContext();
                localContext.setAttribute(ClientContext.AUTH_CACHE, authCache);
         
                return new HttpComponentsConnection(getHttpClient(), httpPost, localContext);
            }
         
            protected abstract UsernamePasswordCredentials getCredentials();
        }

        Would it be possible to include a constructor for HttpComponentsConnection that takes a org.apache.http.protocol.HttpContext?

        Thanks a lot

        Show
        barrypitman Barry added a comment - Hi Arjen, One of my use-cases is that I need to be able to specify different HTTP Basic Auth credentials per request, based on the current user (the context). Looking at the changes at https://fisheye.springsource.org/browse/~br=trunk/spring-ws/trunk/core/src/main/java/org/springframework/ws/transport/http/HttpComponentsConnection.java?r=1981&r=1981 , I don't think that will be possible, because I need to specify a org.apache.http.protocol.HttpContext when making the request. Oleg alluded to using the HttpContext to supply credentials earlier: There are better ways of providing auth credentials at run-time, for instance by binding a custom credentials provider to the local execution context or by using a custom protocol interceptor. For details see: http://hc.apache.org/httpcomponents-client/tutorial/html/authentication.html#d4e909 http://hc.apache.org/httpcomponents-client/tutorial/html/authentication.html#d4e942 The problem is that there is no way to provide a org.apache.http.protocol.HttpContext for httpClient.execute(httpPost, httpContext). What I have been doing in the past is subclassing HttpComponentsMessageSender to override createConnection(URI uri) , creating a HttpComponentsConnection with a HttpContext instance like so: public abstract class BasicAuthHttpComponentsMessageSender extends HttpComponentsMessageSender {   @Override public WebServiceConnection createConnection(URI uri) throws IOException { HttpPost httpPost = new HttpPost(uri); if (isAcceptGzipEncoding()) { httpPost.addHeader(HttpTransportConstants.HEADER_ACCEPT_ENCODING, HttpTransportConstants.CONTENT_ENCODING_GZIP); }   HttpHost targetHost = new HttpHost(uri.getHost(), uri.getPort(), uri.getScheme());   ((DefaultHttpClient) getHttpClient()).getCredentialsProvider().setCredentials( new AuthScope(targetHost.getHostName(), targetHost.getPort()), getCredentials());     AuthCache authCache = new BasicAuthCache(); BasicScheme basicAuth = new BasicScheme(); authCache.put(targetHost, basicAuth);   BasicHttpContext localContext = new BasicHttpContext(); localContext.setAttribute(ClientContext.AUTH_CACHE, authCache);   return new HttpComponentsConnection(getHttpClient(), httpPost, localContext); }   protected abstract UsernamePasswordCredentials getCredentials(); } Would it be possible to include a constructor for HttpComponentsConnection that takes a org.apache.http.protocol.HttpContext ? Thanks a lot
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        I'll take a look tomorrow.

        Show
        arjen.poutsma Arjen Poutsma added a comment - I'll take a look tomorrow.
        arjen.poutsma Arjen Poutsma made changes -
        Status Resolved [ 5 ] Reopened [ 4 ]
        Resolution Complete [ 8 ]
        arjen.poutsma Arjen Poutsma made changes -
        Status Reopened [ 4 ] In Progress [ 3 ]
        arjen.poutsma Arjen Poutsma logged work - 09/May/12 1:53 AM
        • Time Spent:
          31m
           
          <No comment>
        arjen.poutsma Arjen Poutsma made changes -
        Time Spent 5h 37m [ 20220 ] 6h 8m [ 22080 ]
        Worklog Id 28644 [ 28644 ]
        arjen.poutsma Arjen Poutsma made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Complete [ 8 ]
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        I've added a createContext(URI) template method that allows you to create a http context for a given URI. The default implementation returns null.

        Hope that helps!

        Show
        arjen.poutsma Arjen Poutsma added a comment - I've added a createContext(URI) template method that allows you to create a http context for a given URI. The default implementation returns null. Hope that helps!
        Hide
        barrypitman Barry added a comment -

        Great, thanks!

        Show
        barrypitman Barry added a comment - Great, thanks!
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        In Progress In Progress Open Open
        541d 1h 31m 1 Arjen Poutsma 04/May/12 5:14 AM
        Open Open In Progress In Progress
        436d 14h 40m 2 Arjen Poutsma 08/May/12 2:07 AM
        Resolved Resolved Reopened Reopened
        6h 35m 1 Arjen Poutsma 08/May/12 9:38 AM
        Reopened Reopened In Progress In Progress
        15h 43m 1 Arjen Poutsma 09/May/12 1:22 AM
        In Progress In Progress Resolved Resolved
        1h 26m 2 Arjen Poutsma 09/May/12 1:53 AM

          People

          • Assignee:
            arjen.poutsma Arjen Poutsma
            Reporter:
            alankstewart Alan Stewart (personal account)
          • Votes:
            27 Vote for this issue
            Watchers:
            27 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0d
              0d
              Logged:
              Time Spent - 6h 8m
              6h 8m