One of the Axis folks should verify my assumption, of course. But it's
normally a simply matter to fire up a snooper and simply examine the
port numbers. I use either a TCP proxy or Ethereal. The latter provides
low-level, packet-by-packet output but it's a snap to set up and use and
requires no application configuration. Otherwise, you modify Axis2.xml
to point to your favorite debugging proxy and examine its output.

http://www.ethereal.com/

-----Original Message-----
From: Demetris G [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 21, 2007 7:57 PM
To: axis-user@ws.apache.org
Subject: Re: Simple Qs


And that is what I am looking for. I need to be able to monitor the 
outgoing traffic from
the generated (and compiled) stubs without needing to direct the 
application. So if the
outgoing ports are assigned arbitrarily as you say then I will certainly

need to snoop which
ones they are and capture their traffic.

Rich Adili wrote:
> Client sockets are normally assigned an arbitrary port when they
> connect, no? I've had good luck with tools like Ethereal in snooping
> such things without having to instrument the application. 
>
> -----Original Message-----
> From: Demetris G [mailto:[EMAIL PROTECTED] 
> Sent: Monday, May 21, 2007 7:45 PM
> To: axis-user@ws.apache.org
> Subject: Re: Simple Qs
>
>
> Glen - do you know how I can find out on which port the client stubs 
> attempt to
> write to? What determines that? I am assuming the code generating
tools
> read some kind of a configuration before they can attach a port to
write
>
> out
> to?  I am referring to the client side. Which outgoing port do the
stubs
>
> choose
> to write on?
>
> Thanks much
>
> Glen Mazza wrote:
>   
>> Probably, but I really don't know much about the Axis 1.x series.
>>
>> Glen
>>
>>
>> Am Montag, den 21.05.2007, 19:05 -0400 schrieb Demetris G:
>>   
>>     
>>> Hi Glen,
>>>
>>>     thanks for the info. I am assuming the same applies for Axis
1.4?
>>>
>>> Thanks
>>>
>>> Glen Mazza wrote:
>>>     
>>>       
>>>> Am Montag, den 21.05.2007, 17:19 -0400 schrieb Demetris G:
>>>>   
>>>>       
>>>>         
>>>>> I may be reading the overall Axis architecture a bit differently
>>>>>           
> but I 
>   
>>>>> have these Qs if anyone can
>>>>> help -
>>>>>
>>>>> During a Client application call to a remote Axis engine ( SOAP
>>>>>           
> call 
>   
>>>>> generated by the corresponding
>>>>> Client stubs), does an Axis engine need to be running on the
client
>>>>>           
> side 
>   
>>>>> or do the stubs contain
>>>>> the necessary information to generate the SOAP call and contact
the
>>>>>           
>
>   
>>>>> remote Axis engine. 
>>>>>     
>>>>>         
>>>>>           
>>>> The latter.  The Axis2 engine is a WAR file that runs on a Servlet
>>>> container.  The web service is packaged as a service archive (.aar
>>>>         
> file)
>   
>>>> and is placed in the WEB-INF/services directory of the exploded WAR
>>>> file.  You client makes (usually) HTTP requests to access the web
>>>> service, but the Axis engine is not needed for that.
>>>>
>>>>   
>>>>       
>>>>         
>>>>> In other
>>>>> words, if I am sitting on the client side, where should I  be
>>>>>           
> looking at 
>   
>>>>> to capture the outgoing SOAP
>>>>> message leaving a particular application?
>>>>>     
>>>>>         
>>>>>           
>>>> If you wish to capture the message sent by the client, Apache
TCPMon
>>>>         
> may
>   
>>>> be of help for you:
>>>>
>>>> http://ws.apache.org/commons/tcpmon/tcpmontutorial.html
>>>>
>>>> Glen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
> ---------------------------------------------------------------------
>   
>>>> 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]

Reply via email to