You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Jeudy, Guillaume" <gj...@teksystems.com> on 2009/04/15 15:57:14 UTC
Axis2 commons-httpclient 3.1 dependencies
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.
RE: Axis2 commons-httpclient 3.1 dependencies
Posted by George Stanchev <gs...@serena.com>.
There was recent discussion on HTTP client on the axis2 dev list. I suggest
you ask there.
George
_____
From: Jeudy, Guillaume [mailto:gjeudy@teksystems.com]
Sent: Wednesday, April 15, 2009 7:57 AM
To: axis-user@ws.apache.org
Subject: Axis2 commons-httpclient 3.1 dependencies
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.
RE: Access to message context in Password Callback Handler
Posted by Sanjay Gupta <Sa...@billwiseinc.com>.
Hi Sagara,
Thanks for your reply and suggestion. Your suggestion would definitely work. I have used this approach in other applications. I am going to try it.
Sanjay
-----Original Message-----
From: Sagara Gunathunga [mailto:sagara.gunathunga@gmail.com]
Sent: Wednesday, May 20, 2009 10:19 AM
To: axis-user@ws.apache.org
Subject: Re: Access to message context in Password Callback Handler
Hi Sanjay,
I have seen lot of post about this requirement, sometimes ago i also
faced the same issue. AFAIK still there is no proper solution for
this.
cant you use following approach for your requirement..?
1. In callback handler save user profile into a database table after
successful authentication . ( or persist using any other approach.)
2. In the service method retrieve above user profile from database to
access required details.
( I know this is little ugly :) .... but possible solution)
Thanks ,
On Wed, May 20, 2009 at 9:50 PM, Sanjay Gupta
<Sa...@billwiseinc.com> wrote:
> Hi Guys,
>
> Are there any solution to my problem. This seems like a failry common
> requirement. I would really appreciate any help or suggestion.
>
> Thanks
>
> Sanjay
>
>
>
> From: Sanjay Gupta [mailto:Sanjay.Gupta@billwiseinc.com]
> Sent: Friday, May 08, 2009 7:50 AM
> To: axis-user@ws.apache.org
> Subject: RE: Access to message context in Password Callback Handler
>
>
>
> Hi,
>
> Can anybody give me some pointers on this issue.
>
> Sanjay
>
>
>
> From: Sanjay Gupta [mailto:Sanjay.Gupta@billwiseinc.com]
> Sent: Tuesday, April 21, 2009 8:55 AM
> To: axis-user@ws.apache.org
> Subject: Access to message context in Password Callback Handler
>
>
>
> Hi,
>
> I have seen lots on discussion on having access to message context in
> password callback handler in axis2 but no clear solution. I need to store
> some user profile information after successful authentication in callback
> handler so that I can access them in my services(POJO). One option would
> have been to store them in message context and access them in my service but
> message context is not available calback hander. I would really appreciate
> any suggesions.
>
> Thanks
>
> Sanjay
--
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://sagaras.awardspace.com/
Re: Access to message context in Password Callback Handler
Posted by Sagara Gunathunga <sa...@gmail.com>.
Hi Sanjay,
I have seen lot of post about this requirement, sometimes ago i also
faced the same issue. AFAIK still there is no proper solution for
this.
cant you use following approach for your requirement..?
1. In callback handler save user profile into a database table after
successful authentication . ( or persist using any other approach.)
2. In the service method retrieve above user profile from database to
access required details.
( I know this is little ugly :) .... but possible solution)
Thanks ,
On Wed, May 20, 2009 at 9:50 PM, Sanjay Gupta
<Sa...@billwiseinc.com> wrote:
> Hi Guys,
>
> Are there any solution to my problem. This seems like a failry common
> requirement. I would really appreciate any help or suggestion.
>
> Thanks
>
> Sanjay
>
>
>
> From: Sanjay Gupta [mailto:Sanjay.Gupta@billwiseinc.com]
> Sent: Friday, May 08, 2009 7:50 AM
> To: axis-user@ws.apache.org
> Subject: RE: Access to message context in Password Callback Handler
>
>
>
> Hi,
>
> Can anybody give me some pointers on this issue.
>
> Sanjay
>
>
>
> From: Sanjay Gupta [mailto:Sanjay.Gupta@billwiseinc.com]
> Sent: Tuesday, April 21, 2009 8:55 AM
> To: axis-user@ws.apache.org
> Subject: Access to message context in Password Callback Handler
>
>
>
> Hi,
>
> I have seen lots on discussion on having access to message context in
> password callback handler in axis2 but no clear solution. I need to store
> some user profile information after successful authentication in callback
> handler so that I can access them in my services(POJO). One option would
> have been to store them in message context and access them in my service but
> message context is not available calback hander. I would really appreciate
> any suggesions.
>
> Thanks
>
> Sanjay
--
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://sagaras.awardspace.com/
RE: Access to message context in Password Callback Handler
Posted by Sanjay Gupta <Sa...@billwiseinc.com>.
Hi Guys,
Are there any solution to my problem. This seems like a failry common requirement. I would really appreciate any help or suggestion.
Thanks
Sanjay
From: Sanjay Gupta [mailto:Sanjay.Gupta@billwiseinc.com]
Sent: Friday, May 08, 2009 7:50 AM
To: axis-user@ws.apache.org
Subject: RE: Access to message context in Password Callback Handler
Hi,
Can anybody give me some pointers on this issue.
Sanjay
From: Sanjay Gupta [mailto:Sanjay.Gupta@billwiseinc.com]
Sent: Tuesday, April 21, 2009 8:55 AM
To: axis-user@ws.apache.org
Subject: Access to message context in Password Callback Handler
Hi,
I have seen lots on discussion on having access to message context in password callback handler in axis2 but no clear solution. I need to store some user profile information after successful authentication in callback handler so that I can access them in my services(POJO). One option would have been to store them in message context and access them in my service but message context is not available calback hander. I would really appreciate any suggesions.
Thanks
Sanjay
RE: Access to message context in Password Callback Handler
Posted by Sanjay Gupta <Sa...@billwiseinc.com>.
Hi,
Can anybody give me some pointers on this issue.
Sanjay
From: Sanjay Gupta [mailto:Sanjay.Gupta@billwiseinc.com]
Sent: Tuesday, April 21, 2009 8:55 AM
To: axis-user@ws.apache.org
Subject: Access to message context in Password Callback Handler
Hi,
I have seen lots on discussion on having access to message context in password callback handler in axis2 but no clear solution. I need to store some user profile information after successful authentication in callback handler so that I can access them in my services(POJO). One option would have been to store them in message context and access them in my service but message context is not available calback hander. I would really appreciate any suggesions.
Thanks
Sanjay
Access to message context in Password Callback Handler
Posted by Sanjay Gupta <Sa...@billwiseinc.com>.
Hi,
I have seen lots on discussion on having access to message context in password callback handler in axis2 but no clear solution. I need to store some user profile information after successful authentication in callback handler so that I can access them in my services(POJO). One option would have been to store them in message context and access them in my service but message context is not available calback hander. I would really appreciate any suggesions.
Thanks
Sanjay
RE: Axis2 commons-httpclient 3.1 dependencies
Posted by "Jeudy, Guillaume" <gj...@teksystems.com>.
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:gjeudy@teksystems.com]
Sent: Mon 4/20/2009 11:03 AM
To: axis-user@ws.apache.org
Cc: Oleg Kalnichevski
Subject: RE: Axis2 commons-httpclient 3.1 dependencies
Yes you are right Andreas, see comments below:
________________________________
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: Sun 4/19/2009 7:51 AM
To: axis-user@ws.apache.org
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 <gj...@teksystems.com> 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:gjeudy@teksystems.com]
> Sent: Thu 4/16/2009 11:12 AM
> To: axis-user@ws.apache.org
> 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:andreas.veithen@gmail.com]
> Sent: Thu 4/16/2009 10:44 AM
> To: axis-user@ws.apache.org
> 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 <gj...@teksystems.com> 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.
RE: Axis2 commons-httpclient 3.1 dependencies
Posted by "Jeudy, Guillaume" <gj...@teksystems.com>.
Yes you are right Andreas, see comments below:
________________________________
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: Sun 4/19/2009 7:51 AM
To: axis-user@ws.apache.org
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 <gj...@teksystems.com> 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:gjeudy@teksystems.com]
> Sent: Thu 4/16/2009 11:12 AM
> To: axis-user@ws.apache.org
> 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:andreas.veithen@gmail.com]
> Sent: Thu 4/16/2009 10:44 AM
> To: axis-user@ws.apache.org
> 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 <gj...@teksystems.com> 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.
Re: Axis2 commons-httpclient 3.1 dependencies
Posted by Andreas Veithen <an...@gmail.com>.
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.
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].
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 <gj...@teksystems.com> 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:gjeudy@teksystems.com]
> Sent: Thu 4/16/2009 11:12 AM
> To: axis-user@ws.apache.org
> 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:andreas.veithen@gmail.com]
> Sent: Thu 4/16/2009 10:44 AM
> To: axis-user@ws.apache.org
> 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 <gj...@teksystems.com> 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.
>
RE: Axis2 commons-httpclient 3.1 dependencies
Posted by "Jeudy, Guillaume" <gj...@teksystems.com>.
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:gjeudy@teksystems.com]
Sent: Thu 4/16/2009 11:12 AM
To: axis-user@ws.apache.org
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:andreas.veithen@gmail.com]
Sent: Thu 4/16/2009 10:44 AM
To: axis-user@ws.apache.org
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 <gj...@teksystems.com> 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.
RE: Axis2 commons-httpclient 3.1 dependencies
Posted by "Jeudy, Guillaume" <gj...@teksystems.com>.
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:andreas.veithen@gmail.com]
Sent: Thu 4/16/2009 10:44 AM
To: axis-user@ws.apache.org
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 <gj...@teksystems.com> 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.
Re: Axis2 commons-httpclient 3.1 dependencies
Posted by Andreas Veithen <an...@gmail.com>.
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 <gj...@teksystems.com> 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.
Axis2 commons-httpclient 3.1 dependencies
Posted by "Jeudy, Guillaume" <gj...@teksystems.com>.
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.