I posted a JIRA for upgrading axis2 to httpclient 4.0: https://issues.apache.org/jira/browse/AXIS2-4318 Oleg, Andreas, your comments are welcome. Thank you, -Guillaume
________________________________ From: Jeudy, Guillaume [mailto:[email protected]] Sent: Mon 4/20/2009 11:03 AM To: [email protected] Cc: Oleg Kalnichevski Subject: RE: Axis2 commons-httpclient 3.1 dependencies Yes you are right Andreas, see comments below: ________________________________ From: Andreas Veithen [mailto:[email protected]] Sent: Sun 4/19/2009 7:51 AM To: [email protected] Cc: Oleg Kalnichevski Subject: Re: Axis2 commons-httpclient 3.1 dependencies There are actually three areas that depend on commons-httpclient: 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. GJ: Yes, I have made that change locally using patch AXIS2-3933 as a guideline. 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. GJ: Yes, I saw that and I rewrote that code to use mime4j (not tested yet) 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. GJ: Nice moving HTTP transport to a separate module. Last time I checked httpclient 4.0 module is still in beta stage, I think it would be safer to keep both sender implementations around until the 4.0 integration has proven stable. Additionally, not being familiar with axis2 my http transport code may have new bugs or missing functionality that was in the earlier version. 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]. GJ: Good idea, is there any developer doc explaining how axis2.xml schema can be extended ? Andreas [1] http://hc.apache.org/httpcomponents-client/httpmime/index.html [2] http://hc.apache.org/httpcomponents-client/ntlm.html On Fri, Apr 17, 2009 at 22:34, Jeudy, Guillaume <[email protected]> wrote: > Hi Andreas and Co, > > I checked out Axis 1.4 tag since it is the version we use in my company and > started patching it locally. So far, I have made good progress I had to leave > a few httpclient 3.1 functionality commented out because I couldnt find > corresponding functionality in 4.0 (I will ask httpclient group about those). > > I successfully compiled Axis2 kernel with httpclient 4.0 and ran integration > tests with no errors. > > In order to eventually contribute back this work (still in progress) to the > community we need to work around the legal issue with an apache project using > JCIFS library in it's codebase. Because of this here is what I propose: > > -The default axis2.xml http transport configuration should still use > commons-httpclient because there are no legal issues in using this apache > project. > -The axis2 kernel should not need commons-httpclient to compile, therefore > CommonsHTTPTransportSender and helper classes should be moved to a separate > axis2 submodule and true -kernel classes retrofitted to eradicate > commons-httpclient dependencies. > -This will make it easier for a 3rd party(me) to code a new > HttpComponentsTransportSender (HttpComponents 4.0) and swap the default 3.1 > implementation with my 3rd party module at runtime. > > How does that sound? Alternatively axis2 could use by default an upgraded > CommonsHTTPTransportSender with no NTLM support (because of the legal issues). > > Let me know your thoughts, > > Thanks, > Guillaume > > ________________________________ > > From: Jeudy, Guillaume [mailto:[email protected]] > Sent: Thu 4/16/2009 11:12 AM > To: [email protected] > Subject: RE: Axis2 commons-httpclient 3.1 dependencies > > > Andreas, > > I have looked at AXIS2-3933 and I'm not sure the patch is complete. > > I was thinking to create a new transport as to avoid recompiling axis2 with > httpclient 4.0 and hopefully save some time. Additionnally I was planning to > hard-code NTLMv2 support into that transport using JCIFS library as outlined > here: http://hc.apache.org/httpcomponents-client/ntlm.html. I don't think > such support should be committed in axis2 trunk because there are legal > implications: > > "JCIFS is licensed under the Lesser General Public License (LGPL). This > license is not compatible with the Apache Licenses under which all Apache > Software is released. Lawyers of the Apache Software Foundation are currently > investigating under which conditions Apache software is allowed to make use > of LGPL software." > > Hardcoding axis2 to use httpclient 4.0 is the best long term solution for the > trunk as long as nothing outside the CommonsHTTPTransportSender and it's > apparatus are directly dependent of httpclient library. > > I guess I could find a way to upgrade CommonsHTTPTransportSender to > httpclient 4.0 without any NTLM support (that is a step backwards considering > httpclient 3.1 has limited NTLMv1 support). Additionnally you will have to > advise me; find some kind of pluggable mechanism that allows a user through > configuration to add NTLM support (with jcifs library). > > I haven't looked into more details for the changes required to upgrade > CommonsHTTPTransportSender yet. > > Thanks, > -Guillaume > > ________________________________ > > From: Andreas Veithen [mailto:[email protected]] > Sent: Thu 4/16/2009 10:44 AM > To: [email protected] > Subject: Re: Axis2 commons-httpclient 3.1 dependencies > > > > Guillaume, > > I think it's a great idea to upgrade to a recent version of > httpclient. One of the prerequisite would be to solve AXIS2-3933 so > that axis2-kernel no longer depends on commons-httpclient. Since Axis2 > 1.5 is going to be released soon, we can again do larger changes to > the trunk. Also, there is a patch available for AXIS2-3933, so we > could solve that issue quite quickly. This will also tell us if there > is any code in Axis2 that has a hidden dependency on > commons-httpclient. > > For CommonsHTTPTransportSender, I think we should avoid creating a > "new" transport sender. I would suggest that you do your changes on a > well defined version of the transport so that we can later commit > these changes to the codebase. Did you already start to analyze the > amount of changes that are required to upgrade > CommonsHTTPTransportSender to commons-httpclient 4.0? > > Andreas > > On Wed, Apr 15, 2009 at 15:57, Jeudy, Guillaume <[email protected]> wrote: >> Hi, >> >> I'm considering upgrading axis2 to use the new httpclient 4.0 in conjunction >> with jcifs library in order to support HTTP NTLMv2 connections. I need >> feedback from axis2 contributors/developers. >> >> Please confirm what steps I should take to achieve that. >> >> 1. Implement a new TransportSender using httpclient 4.0. I'm hoping I can >> base my code on the existing CommonsHTTPTransportSender and port it to use >> httpclient 4.0. >> >> 2. Modify axis2.xml to use my new TransportSender. >> >> Can anyone tell me if there are any hidden runtime dependencies I should be >> aware of? Based on the axis2 source code analysis I made; it seems like >> httpclient 3.1 is only used in CommonsHTTPTransportSender class and that >> class can be completely ignored at runtime if axis2.xml is not configured to >> use it, please correct me if i'm wrong. >> >> Thank you! >> -Guillaume Jeudy >> >> ________________________________ >> This electronic mail (including any attachments) may contain information >> that is privileged, confidential, and/or otherwise protected from disclosure >> to anyone other than its intended recipient(s). Any dissemination or use of >> this electronic email or its contents (including any attachments) by persons >> other than the intended recipient(s) is strictly prohibited. If you have >> received this message in error, please notify us immediately by reply email >> so that we may correct our internal records. Please then delete the original >> message (including any attachments) in its entirety. Thank you. > > > > > > ____________________________________________________________________________________________________ > This electronic mail (including any attachments) may contain information that > is privileged, confidential, and/or otherwise protected from disclosure to > anyone other than its intended recipient(s). Any dissemination or use of this > electronic email or its contents (including any attachments) by persons other > than the intended recipient(s) is strictly prohibited. If you have received > this message in error, please notify us immediately by reply email so that we > may correct our internal records. Please then delete the original message > (including any attachments) in its entirety. Thank you. > ________________________________ This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you. ____________________________________________________________________________________________________ This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
