CXF
  1. CXF
  2. CXF-291

Support Commons HTTP Client for HTTP conduit

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.7.0
    • Component/s: Transports
    • Labels:

      Description

      I think commons http client is a must in terms of HTTP support as it supports a lot of different authentication modes that I don't know that we currently support. It shouldn't be that hard to integrate either. XFire users tend to depend pretty heavily on it. The XFire code can be found here:

      http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/transport/http/CommonsHttpMessageSender.java

        Issue Links

          Activity

          Dan Diephouse created issue -
          Bozhong Lin made changes -
          Field Original Value New Value
          Fix Version/s 2.0-RC [ 12312047 ]
          Affects Version/s 2.0-M1 [ 12312044 ]
          Affects Version/s 2.0 [ 12312174 ]
          Fix Version/s 2.0 [ 12312174 ]
          Dan Diephouse made changes -
          Fix Version/s 2.0 [ 12312174 ]
          Fix Version/s 2.0.1 [ 12312401 ]
          Daniel Kulp made changes -
          Fix Version/s 2.0.1 [ 12312401 ]
          Fix Version/s 2.1 [ 12312402 ]
          Daniel Kulp made changes -
          Component/s Transports [ 12311342 ]
          Daniel Kulp made changes -
          Fix Version/s 2.1 [ 12312402 ]
          Hide
          Guillaume Carre added a comment -

          An example of authentication mode that doesn't work with the current HTTPConduit is Digest Authentication.

          Show
          Guillaume Carre added a comment - An example of authentication mode that doesn't work with the current HTTPConduit is Digest Authentication.
          Daniel Kulp made changes -
          Labels gsoc
          Daniel Kulp made changes -
          Labels gsoc gsoc2011
          Hide
          Daniel Kulp added a comment -

          Some work was started on this on a branch, but it hasn't been updated with the latest CXF changes and it needs quite a bit of cleanup and testing.

          Show
          Daniel Kulp added a comment - Some work was started on this on a branch, but it hasn't been updated with the latest CXF changes and it needs quite a bit of cleanup and testing.
          Mark Thomas made changes -
          Workflow jira [ 12391586 ] Default workflow, editable Closed status [ 12605938 ]
          Hide
          Stephane Routhiau added a comment -

          Hi Daniel,

          Thanks for working of this old issue.

          Do you have a release date from this issue ?

          Where can we find the code proposed for correction ?

          regards,

          Show
          Stephane Routhiau added a comment - Hi Daniel, Thanks for working of this old issue. Do you have a release date from this issue ? Where can we find the code proposed for correction ? regards,
          Hide
          Daniel Kulp added a comment -

          The code was on a branch I created a long time ago:
          http://svn.apache.org/repos/asf/cxf/branches/async-client/

          with the specific code in:
          http://svn.apache.org/repos/asf/cxf/branches/async-client/rt/transports/http/src/main/java/org/apache/cxf/transport/http/async/

          That said, I started that all before 2.3.0 was released so it's definitely a bit out of date and would need some refactoring. If I remember correctly, I has most of the non-SSL cases working. I hadn't started on the SSL stuff at all. Not really 100% possitive though. For the most part, it hasn't been a priority as it didn't provide any major benefit over the HTTPURLConnection for the normal CXF usecases and actually performs slightly slower. However, for async calls, it could have some benefit. More details:

          http://cxf.547215.n5.nabble.com/Async-HTTP-client-side-td2835428.html

          Show
          Daniel Kulp added a comment - The code was on a branch I created a long time ago: http://svn.apache.org/repos/asf/cxf/branches/async-client/ with the specific code in: http://svn.apache.org/repos/asf/cxf/branches/async-client/rt/transports/http/src/main/java/org/apache/cxf/transport/http/async/ That said, I started that all before 2.3.0 was released so it's definitely a bit out of date and would need some refactoring. If I remember correctly, I has most of the non-SSL cases working. I hadn't started on the SSL stuff at all. Not really 100% possitive though. For the most part, it hasn't been a priority as it didn't provide any major benefit over the HTTPURLConnection for the normal CXF usecases and actually performs slightly slower. However, for async calls, it could have some benefit. More details: http://cxf.547215.n5.nabble.com/Async-HTTP-client-side-td2835428.html
          Hide
          Oleg Kalnichevski added a comment -

          @Daniel

          For what it is worth to you.

          You could base your client side HTTP code on the asynchronous version of HttpClient [1] which would relieve the tedium of having to deal with the non-blocking SSL (which is enormously painful), persistent connection management, and similar low level stuff and help cut down on the amount of HTTP protocol specific code quite dramatically. HttpAsyncClient is also based on HttpCore NIO so migration should be fairly straightforward.

          As far as performance is concerned, it is perfectly expectable for a NIO based transport to be ~25% slower in terms of raw throughput than a similar one based on the classic (blocking) I/O model. Thread context switching in modern JREs tends to be faster than selector based channel multiplexing.

          Oleg

          [1] http://hc.apache.org/httpcomponents-asyncclient-dev/index.html

          Show
          Oleg Kalnichevski added a comment - @Daniel For what it is worth to you. You could base your client side HTTP code on the asynchronous version of HttpClient [1] which would relieve the tedium of having to deal with the non-blocking SSL (which is enormously painful), persistent connection management, and similar low level stuff and help cut down on the amount of HTTP protocol specific code quite dramatically. HttpAsyncClient is also based on HttpCore NIO so migration should be fairly straightforward. As far as performance is concerned, it is perfectly expectable for a NIO based transport to be ~25% slower in terms of raw throughput than a similar one based on the classic (blocking) I/O model. Thread context switching in modern JREs tends to be faster than selector based channel multiplexing. Oleg [1] http://hc.apache.org/httpcomponents-asyncclient-dev/index.html
          Hide
          Stephane Nicoll added a comment -

          Daniel,

          Any chance to get that support in the next CXF release?

          Thanks.

          Show
          Stephane Nicoll added a comment - Daniel, Any chance to get that support in the next CXF release? Thanks.
          Hide
          Shaun Elliott added a comment -

          I too would like to see this happen. CXF doesn't work well with NTLM, but the Commons HTTP client does. This is just one of many possible use cases for allowing developers to swap out the underlying client.

          Show
          Shaun Elliott added a comment - I too would like to see this happen. CXF doesn't work well with NTLM, but the Commons HTTP client does. This is just one of many possible use cases for allowing developers to swap out the underlying client.
          Hide
          Daniel Kulp added a comment -

          The CXF trunk code (targeting 2.7.0) now has an optional AsyncClient based transport. Some information at:

          http://cxf.apache.org/docs/asynchronous-client-http-transport.html

          Show
          Daniel Kulp added a comment - The CXF trunk code (targeting 2.7.0) now has an optional AsyncClient based transport. Some information at: http://cxf.apache.org/docs/asynchronous-client-http-transport.html
          Hide
          Daniel Kulp added a comment -


          Marking this resolved for 2.7.0 as all the CXF tests pass when using it instead of the older HTTPUrlConnection based transport. Thus, it's considered feature complete. Any "issues" with it would now be considered bugs.

          Show
          Daniel Kulp added a comment - Marking this resolved for 2.7.0 as all the CXF tests pass when using it instead of the older HTTPUrlConnection based transport. Thus, it's considered feature complete. Any "issues" with it would now be considered bugs.
          Daniel Kulp made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Assignee Daniel Kulp [ dkulp ]
          Fix Version/s 2.7.0 [ 12321669 ]
          Resolution Fixed [ 1 ]
          Shaun Elliott made changes -
          Link This issue is related to CXF-4525 [ CXF-4525 ]
          Hide
          Shaun Elliott added a comment -

          Ok, great thanks. I have filed a new improvement task to get at the underlying client. As is, it still does not solve my use case (NTLM authentication).

          Show
          Shaun Elliott added a comment - Ok, great thanks. I have filed a new improvement task to get at the underlying client. As is, it still does not solve my use case (NTLM authentication).
          Daniel Kulp made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Daniel Kulp
              Reporter:
              Dan Diephouse
            • Votes:
              29 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development