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




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to