[
https://issues.apache.org/jira/browse/AXIS2-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711631#action_12711631
]
Guillaume Jeudy commented on AXIS2-4318:
----------------------------------------
I do have a locally patched axis2 version that works with NTLMv2 authentication
but it is not published here. I don't think the patch is ready for axis2 trunk
because it has missing features (I couldnt find an easy to port for some of the
features as outlined in the initial JIRA description), therefore it would be
unacceptable for broad consumption if such features disappeared with the
upgrade.
What you can do is vote for this issue and hope that it gets attention from the
Axis2 developers. I'm not an Axis2 developer and never committed anything to
axis2 and therefore need guidance from the axis2 devs which haven't been very
responsive to this JIRA issue so far.
> 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.
