[wsf-c-dev] Using TCPMon C Tool
Senaka Fernando
senaka at wso2.com
Wed Mar 5 03:42:53 PST 2008
Hi Paul,
The GUI is an afterthought, and is not a real requirement rather. This is
just an add-on for users who prefer Graphical front-ends. Of course even
with a GUI it is still different to Java, as it does not require a runtime
environment to execute. :)...
And, the TCPMon GUI can be made available as a WSO2 product rather than an
ASF product as it is a value addition rather than a requirement.
It does log. But, how could we support a edit and resend operation? That's
why I thought of a request.xml. OK, we can do something like this.
If you say resend m, it will simply resend request m. And, if you say
"edit and resend", it will create a request.xml (or at your option having
some other filename) out of request m, which can be edited. Then you can
call resend, with request.xml as an argument. This will give you the
opportunity to use different file names per edited & resent request.
BTW, this will all happen within the command line exposed by the running
TCPMon instance, so that only a single executable would be required.
How about that?
Regards,
Senaka
> Senaka
>
> I don't think having a GUI is so useful. I think you should concentrate
> on what makes this *different* from the Java TCPMON - the great command
> line support.
>
> If you want to make a resend work simply, I would create a logging
> approach:
> * set TCPMON to log to a file
> * record n message interactions
> * use the command line to point to the file and request it to resend
> request number m.
>
> Paul
>
> Senaka Fernando wrote:
>> Hi Paul, Samisa, and others,
>>
>> Currently, as TCPMon is a part of Axis2/C, did not try to make it
>> possible
>> to build it without Axis2/C. Will try to have a TCPMon only build.sh,
>> and
>> build.bat, so that if someone downloads TCPMon only, plus the relevant
>> Axis2/C libraries, it should basically work. Then it would be possible
>> to
>> create a single exe, plus 2-3 dlls which can be packed to a single zip.
>>
>> Also, I suggest to make our win32 build systems build TCPMon by default,
>> even on Axis2/C.
>>
>> Considering Samisa's reply to my previous mail, it is possible to
>> provide
>> option to toggle XML Formatting. Like for instance, pressing 'q'
>> followed
>> by Enter will quit. Similarly, we can have something like pressing 'f'
>> for
>> this purpose.
>>
>> You can read through the message history, as it would be written to the
>> stdout stream.
>>
>> However, resending messages will need some new logic. :)... Wondering
>> how
>> this could be done in a command line tool. The best I can think of is to
>> have a resend.xml, that can be edited and resent. This is better than a
>> resend.txt, because we need to identify several components in a request,
>> such as,
>>
>> 1. host:port
>> 2. headers
>> 3. payload
>> 4. HTTP Method
>>
>> Otherwise this will lead to something like rewriting a curl command
>> line.
>> :D..
>>
>> Also, it is possible to create a C++ GUI front-end for TCPMon, once we
>> have all these features in place. Thoughts?
>>
>> Regards,
>> Senaka
>>
>>> Is there any way you can build tcpmon.exe for Windows that includes all
>>> the dependencies? I did download everything to get tcpmon working, but
>>> I
>>> think it would be nice to have a single exe. You might get some wider
>>> usage that way.
>>>
>>> Paul
>>>
>>> Senaka Fernando wrote:
>>>> Hi All,
>>>>
>>>> It seems that we still use the TCPMon Java tool despite that we've
>>>> fixed
>>>> the TCPMon C tool, to work just the same as the Java tool (probably
>>>> better
>>>> than the Java tool). We do have some advantages in the C tool,
>>>> basically,
>>>>
>>>> 1. The TCPMon Traffic log
>>>> 2. Ability to handle MTOM without crashing :)...
>>>> 3. Support for chunked requests
>>>>
>>>> Which the TCPMon Java tool lacks. Therefore, it is rather nice if you
>>>> are
>>>> interested in switching to the C tool. This will also help us uncover
>>>> any
>>>> unattended bugs, which are quite a few I believe.
>>>>
>>>> Also, we do have XML Formatting, introduced by Milinda (intern
>>>> 2006/2007),
>>>> which can be used with the '--format' option.
>>>>
>>>> Regards,
>>>> Senaka
>>>>
>>>>> Samisa Abeysinghe wrote:
>>>>>> Manoj wrote:
>>>>>>> Samisa Abeysinghe wrote:
>>>>>>>> Manoj wrote:
>>>>>>>>> Manoj wrote:
>>>>>>>>>> hi all,
>>>>>>>>>> There are some cases which we need to do fault handling in our
>>>>>>>>>> PHP
>>>> dataservice.
>>>>>>>>>> Eg
>>>>>>>>>> 1)when there are no data in the table.
>>>>>>>>>> 2)when the table doesn't exist.
>>>>>>>>>> 3)when the database doesn't exist.
>>>>>>>>>> 4)queries which are return null values.
>>>>>>>>>> The JAVA people sending custom errors massages for
>>>>>>>>>> those
>>>>>>>>>> faults.They don't do AXIS level fault handling. Can anybody
>>>>>>>>>> explain
>>>> the way which we need to handle those faults.
>>>>>>>> We can send a SOAP fault with a custom fault reason.
>>>>>>>> Samisa...
>>>>>>> Hi samisa,
>>>>>>> In according to nandika's idea currently we send the custom fault
>>>> reason inside the <error> element. Is that good enough?
>>>>>>> Eg: Response = <ds:customer-addresses
>>>>>>> xmlns:ds="http://wso2.org/projects/wsf/php/ds"><error>table not
>>>> found</error></ds:customer-addresses>
>>>>>> Is there a complete SOAP message captured with a full fault.
>>>>>> Samisa...
>>>>> I attached the full fault with this.
>>>>> _______________________________________________
>>>>> Wsf-c-dev mailing list
>>>>> Wsf-c-dev at wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Wsf-c-dev mailing list
>>>> Wsf-c-dev at wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>>>>
>>> --
>>> Paul Fremantle
>>> Co-Founder and VP of Technical Sales, WSO2
>>> OASIS WS-RX TC Co-chair
>>>
>>> Office: +1 646 290 8050
>>> Cell: +44 798 447 4618
>>>
>>> blog: http://pzf.fremantle.org
>>> paul at wso2.com
>>>
>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>
>>
>>
>> _______________________________________________
>> Wsf-c-dev mailing list
>> Wsf-c-dev at wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> Office: +1 646 290 8050
> Cell: +44 798 447 4618
>
> blog: http://pzf.fremantle.org
> paul at wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
More information about the Wsf-c-dev
mailing list