[
https://issues.apache.org/jira/browse/AXIS2-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711675#action_12711675
]
George Stanchev commented on AXIS2-4318:
----------------------------------------
Guillaume, can you attach your patch and indicate the svn revision # you have
done it against so when/if an axis2 committer picks it up to have a starting
point. I am also intrested in your patch regardless if it is commital-ready.
> Upgrade CommonsHTTPTransportSender to use httpclient 4.0
> --------------------------------------------------------
>
> Key: AXIS2-4318
> URL: https://issues.apache.org/jira/browse/AXIS2-4318
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Affects Versions: 1.4.1
> Reporter: Guillaume Jeudy
>
> 3 areas currently using commons-httpclient 3.1:
> 1. The code that interfaces between Axis2 and the underlying
> transport, e.g. the Stub class. This code only refers to
> org.apache.commons.httpclient.Header and could easily be made
> independent of commons-httpclient. This is what the patch in
> AXIS2-3933 does.
> 2. MultipartFormDataFormatter uses code from commons-httpclient to
> build multipart/form-data requests. Maybe this code should be
> rewritten to use HttpMime [1] and/or mime4j.
> 3. The code in the HTTP transport. Note that in Axis2 1.5 this code is
> no longer part of the kernel and lives in a separate module. The core
> question here is whether we should upgrade that code from
> commons-httpclient 3.1 to HttpClient 4.0 or if it is better to keep
> two separate transport sender implementations (at least temporarily).
> It would be interesting to get Oleg's opinion on this.
> For the legal issue around NTLM, I think the best solution is to allow
> the user to register additional AuthSchemeFactory classes in the
> transport configuration in axis2.xml. People who need NTLM can than
> use the code from [2].
> [1] http://hc.apache.org/httpcomponents-client/httpmime/index.html
> [2] http://hc.apache.org/httpcomponents-client/ntlm.html
> I am willing to provide a patch to upgrade to httpclient 4.0. I have
> completed some work locally and I believe most of the existing functionality
> has been replicated successfully in httpclient 4.0 but still more areas need
> to be settled before the local work becomes a candidate for commit into the
> trunk.
> Unanswered questions/proposals:
> 1) I assume upgrading to httpclient 4.0 rather than providing a separate
> transport is the best long term solution.
> 2) Drop support for HTTPConstants.CUSTOM_PROTOCOL_HANDLER option
> Reason DefaultHttpClient already supports http and https schemes by default
> do we really want to allow a user to use a different scheme/socketfactory
> combination? This doesn't seem to be a commonly used feature.
> If we still need to support this option then an instance of Scheme would need
> to be passed in by the user and registered in the SchemeRegistry in turn used
> to build the HttpClient. We can no longer use a DefaultHttpClient if we do
> this, we would have to extend it most likely.
> 3) drop authenticator preemptive authentication support
> Preemptive authentication is considered unsecure and is strongly discouraged.
> Moreover the code found in examples:
> http://hc.apache.org/httpcomponents-client/examples.html is no longer
> officially supported. Which means that we should drop preemptive
> authentication support from the trunk; alternatively we can allow a number of
> pluggable mechanisms to allow users to enable preemptive auth. The user would
> have to provide HttpRequestInterceptor and HttpResponseInterceptor
> implementations as well as a means to properties to configure a
> BasicHttpContext for use with the HttpClient. As a workaround/alternative the
> user could fully initialize it's own AbstractHttpClient instance and pass it
> through the existing CACHED_HTTP_CLIENT option.
> 3) Drop support for HTTPConstants.AUTO_RELEASE_CONNECTION
> httpclient 4.0 already releases http connections (to the connection pool)
> after every http method execution. Therefore this property becomes obsolete.
> 4) Axis2 and java compiler source compliance setting? I see that some axis2
> modules still compile with 1.4 source compliance. Should this be supported?
> On mailing lists I saw that Axis2 already started moving to java 5. Should
> Axis2 1.4 kernel module still use java compliance 1.4, should we change
> source compliance for the kernel to 1.5?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
