We will try to ship this improvement with 1.7.0 release. Since this effort require lot of refactoring it is not possible to include to a miner release.
Thanks ! On Fri, Mar 2, 2012 at 8:52 PM, George Stanchev <gstanc...@serena.com>wrote: > Hi Sagara, > > Which Axis2 release is the new HTTP Client 4.x sender slated for? Next > 1.6.x or 1.7.0 release? Or both? > > George > > -----Original Message----- > From: Sagara Gunathunga (Commented) (JIRA) [mailto:j...@apache.org] > Sent: Thursday, March 01, 2012 11:57 PM > To: java-dev@axis.apache.org > Subject: [jira] [Commented] (AXIS2-4318) Upgrade > CommonsHTTPTransportSender to use httpclient 4.0 > > > [ > https://issues.apache.org/jira/browse/AXIS2-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220738#comment-13220738] > > Sagara Gunathunga commented on AXIS2-4318: > ------------------------------------------- > > Refactored few test cases in r1295542. > > > Upgrade CommonsHTTPTransportSender to use httpclient 4.0 > > -------------------------------------------------------- > > > > Key: AXIS2-4318 > > URL: https://issues.apache.org/jira/browse/AXIS2-4318 > > Project: Axis2 > > Issue Type: Improvement > > Affects Versions: 1.4.1 > > Reporter: Guillaume Jeudy > > Assignee: Sagara Gunathunga > > Attachments: > > axis2-1.6.1-patch-for-httpclient4.1-WORK-IN-PROGESS.diff, > > 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. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org > For additional commands, e-mail: java-dev-h...@axis.apache.org > > > -- Sagara Gunathunga Blog - http://ssagara.blogspot.com Web - http://people.apache.org/~sagara/ LinkedIn - http://www.linkedin.com/in/ssagara
