axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kishanthan Thangarajah (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AXIS2-4318) Upgrade CommonsHTTPTransportSender to use httpclient 4.0
Date Sun, 06 May 2012 10:15:51 GMT

    [ https://issues.apache.org/jira/browse/AXIS2-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269173#comment-13269173
] 

Kishanthan Thangarajah commented on AXIS2-4318:
-----------------------------------------------

I'm adding some info about the main class HTTPSenderImpl which handles all REST methods and
requests. 
In httpclient3 impl for above same class, what we are doing is we handle the response in executing
a method by referring the method it self. Because, after executing, the method itself will
hold the information like, status, statusCode, responseHeaders etc. 
But in httpclient4, when executing a method, it returns a HttpResponse object. This object
only, holds all the detail about the status of the method which was executed and also the
response entites from executed method. So the possible way is to return the HttpResponse from
executeMethod and use this response object in handling and processing the response, entities
and status etc.
Further, when setting timeout values we don't have set separately for the connection managers
in hc4, instead we can set it to the client it self, which will be timeout values for connection
manger as-well.
I'm also adding a small fix for a typo in httpclient3 impl for ProxyConfigurator class.

Kishanthan.
                
> 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-4318_01.patch, AXIS2-4318_02.patch, AXIS2-4318_03.patch, AXIS2-4318_04.patch,
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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message