Ethereal is a packet sniffer, not a proxy. So the output is different. A
proxy provides high-level output (http message exchanges). A packet
sniffer just dumps packets out. The latter can be a bit of a learning
curve if you're new to such.

I've not used tcpmon. Being a Windows weenie I like tools that fire up
and run without need of reading manuals or posting questions on mailing
lists :-). Less work that way. I think tcpmon works as a proxy so you
will need to modify Axis2.xml to point to it.

Either way, you don't need to know the client port # in advance. You
will need to know the server URL so you can configure the proxy and/or
filter out unwanted messages.

Rich

-----Original Message-----
From: Demetris G [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 21, 2007 8:08 PM
To: [email protected]
Subject: Re: Simple Qs


Sure thing - I will take a look at Ethereal and see if it can help me.

Others have also mentioned tcpmon - I am assuming that could only work 
if the
port number is known. Right ? Cause you will need to direct the outgoing

traffic
through tcpmon before it can reach its destination. I think ...

Rich Adili wrote:
> 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: [email protected]
> 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: [email protected]
>> 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]
>
>
>
>   

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