Oh! So with Axis2.1 I can't bind the client stubs to an IP address you mean ?
regards, Niranjan -----Original Message----- From: ext Andreas Veithen [mailto:[email protected]] Sent: Tuesday, March 29, 2011 11:13 AM To: [email protected] Subject: Re: AXIS2: fixing client sockets used I think that 4.0 is not compatible with 3.1. Therefore upgrading is non trivial and will require updates to the Axis2 code. Andreas On Tue, Mar 29, 2011 at 06:14, Bhat B, Niranjan (NSN - IN/Bangalore) <[email protected]> wrote: > > --cut-- > it is indeed a valid requirement to be able to select the > IP address. I think that this is supported in HttpClient 4.0, but not > in 3.1 (which is the version used by Axis2). > --cut-- > Oh great! > So is it ok that I can just change the Commons HTTP Client from 3.1 to 4.0 in > the axis2 webapplication manually and then make some changes in the generated > stubs for me to get this working ? > > > regards, > Niranjan > > -----Original Message----- > From: ext Andreas Veithen [mailto:[email protected]] > Sent: Monday, March 28, 2011 11:21 PM > To: [email protected] > Subject: Re: AXIS2: fixing client sockets used > > If the IP addresses are in different subnets, then the OS will select > the right one. If the machine has multiple IP addresses in the same > subnet, then it is indeed a valid requirement to be able to select the > IP address. I think that this is supported in HttpClient 4.0, but not > in 3.1 (which is the version used by Axis2). > > Andreas > > On Mon, Mar 28, 2011 at 15:04, Bhat B, Niranjan (NSN - IN/Bangalore) > <[email protected]> wrote: >> Hi Andreas, >> >> Thanks for the help ! And I get your point. >> Could you please let me know that is it possible to bind these clients >> to send a  request from a particular IP address/IP interface on the >> machine ? This case might occur when the same machine will have multiple >> IP addresses . >> >> >> regards, >> Niranjan >> >> -----Original Message----- >> From: ext Andreas Veithen [mailto:[email protected]] >> Sent: Thursday, March 24, 2011 8:55 PM >> To: java-user >> Subject: Re: AXIS2: fixing client sockets used >> >> If I understand your requirement correctly, you would like Axis2 to >> bind the local side of the HTTP connection to a fixed port (using >> Socket#bind [1]). This is not supported for two reasons: >> >> 1. Axis2 uses commons httpclient which AFAIK doesn't support this. >> 2. The tuple (src IP, src port, dst IP, dst port) must be unique for a >> each TCP connection. Binding to a fixed port would mean that you could >> open at most one connection to the destination. This is generally not >> what you want for HTTP. >> >> Andreas >> >> [1] >> http://download.oracle.com/javase/1.5.0/docs/api/java/net/Socket.html#bi >> nd(java.net.SocketAddress) >> >> On Thu, Mar 24, 2011 at 06:37, Bhat B, Niranjan (NSN - IN/Bangalore) >> <[email protected]> wrote: >>> >>> Hi Axis2 users, >>> >>> I have been asked to fix the socket used by the axis2 stubs (which is >>> random currently )to a fixed socket. >>> >>> Details: >>> Everytime my axis2 client stubs tries to contact the webservice( again >>> running on axis2) it opens a random port on the client IP on which it >>> sends request to the server IP and a fixed server port. >>> I want to fix this random port on the client IP to a fixed port, so >> that >>> my product can be hardened. >>> Also I am running this client from within Tomcat6 as a web >> application. >>> >>> regards, >>> Niranjan >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
