[ https://issues.apache.org/jira/browse/AXIS2-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711823#action_12711823 ]
Guillaume Jeudy commented on AXIS2-4318: ---------------------------------------- forgot to say, I checked out axis2 with axis2_14 tag before developing the patch. > 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 > Attachments: workinprogress.patch > > > 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.