[jira] Created: (AXIS2-4318) Upgrade CommonsHTTPTransportSender to use httpclient 4.0

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.

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

Marko Asplund commented on AXIS2-4318:
--------------------------------------

Has there been any progress on this issue?

I'm currently trying to make a Java web application talk to Microsoft Sharepoint server web services using Axis2 and authentication has proven to be the trickiest part. HttpClient 3.1 only seems to support NTLM v1 which is not enabled by default on newer Windows servers and administrators don't usually allow using it.
NTLM autentication works well with HttpClient 4.0 + JCIFS though.

> 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.

    [ 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.

    [ 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.

     [ https://issues.apache.org/jira/browse/AXIS2-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Jeudy updated AXIS2-4318:
-----------------------------------

    Attachment: workinprogress.patch

I added all the patch info. Let me know if that is any help to you guys.

I had to use a BufferedHttpEntity in AbstractHTTPSender.processResponse() because otherwise the http connections would never be released when the transport is used with REUSE_HTTP_CLIENT mode.

Note: this decision is controversial because you buffer the whole input stream in memory, that wouldnt work if you expect very large responses from your HTTP SOAP call...

It seems like axis toplevel classes is using a PushbackInputStream which defeats the http client EofSensorInputStream that is supposed to detect the end of the stream and release the underlying http connection. An axis2 developer's advice would be welcome here. Ideally we want the EofSensorInputStream to do it's job and not have to buffer the whole response in memory...

Regards,
-Guillaume

> 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.

    [ 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.

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

Andreas Veithen commented on AXIS2-4318:
----------------------------------------

Applying the changes to the trunk and maintaining them afterwards will be quite challenging. There are several reasons for this:
- The baseline for the patch is 1.4 and there have been other fixes and changes in the code.
- Since 1.4, the code of the HTTP transport has been moved twice (first to WS-Commons Transport and than back to Axis2 into a separate Maven module). What makes it worse is that the first move was not done correctly (local copy + svn add instead of svn copy/move), so that it's difficult to get the version history back to 1.4.
- The conclusion of the discussion on the mailing list [1] was to keep implementations for both commons-httpclient 3.1 and for httpclient 4.0, which I believe is a good thing. On the other hand this means that instead of just applying the patch and throwing out commons-httpclient, we need to create some sort of fork. From Guillaume's patch it is clear that these two implementations will have a lot of duplicate logic and code. This will cause maintenance issues (fixes or enhancements applied to one implementation, but not the other, etc.).

For these reasons I would prefer a different approach, which is to first refactor the current HTTP implementation to isolate all the commons-httpclient 3.1 specific code from the purely Axis2 related code that would be common to the two implementations. Using Guillaume's experience we would then build a httpclient 4.0 implementation on top of it.

This is only realistic if we can build a group of people who support that effort by analyzing the existing code, contributing new code and/or actively testing the code. Who of you is ready to support this effort? Please note that the baseline for this development would be Axis2 1.5 (which will be released next week).

[1] http://markmail.org/thread/m2tsumqxvfiel2bg

> 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.

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

Hendry Betts III commented on AXIS2-4318:
-----------------------------------------

as it stands now, I am going to have to completely re-write my axis based service classes to communicate with SharePoint.  I *wish* this was already done.

> 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.

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

Hendry Betts III edited comment on AXIS2-4318 at 11/2/09 7:58 PM:
------------------------------------------------------------------

as it stands now, I am going to have to completely re-write my axis based service classes to communicate with SharePoint.  I *wish* this was already done.  Andreas, I will help however I can.

      was (Author: hbetts3):
    as it stands now, I am going to have to completely re-write my axis based service classes to communicate with SharePoint.  I *wish* this was already done.
 

> 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.

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

Marko Asplund commented on AXIS2-4318:
--------------------------------------


AFAIK, SPNEGO support has been added to Commons HttpClient 4.1 branch (see HTTPCLIENT-523).
This should make many people that need to integrate with SharePoint very happy.

> 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.

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

Hendry Betts III commented on AXIS2-4318:
-----------------------------------------

Marko,  this is all well and good.  In fact, for the solution I am having to engineer I am using HTTPClient 4.1.  But I would rather not have to replicate functionality in Axis2 simply because the client module isn't "up-to-date"

> 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.