[
https://issues.apache.org/jira/browse/AXISCPP-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647434#action_12647434
]
nadiramra edited comment on AXISCPP-100 at 11/20/08 2:16 PM:
--------------------------------------------------------------
OK, finally got this done. Tracing is now integrated in the code so that only
one binary is needed when we put out a release. I have also disabled and
removed the previous support in which a tool was used to dynamically produce
source with a trace points. That was kludgy and introduced complexity when
trying to do tracing of the xml parser and transport, and channels. It is much
cleaner now. Here is the information on the support.
To enable tracing, simply set one of ClientLogPath or LogPath (for server
logging) to the path of the trace file in the axiscpp.conf file. With this
support, a new configuration variable, LogFilter, can be set to filter the
trace records so you can isolate a component. The filter is a semicolon
delimited string of possible filters. Possible filters include:
* stub - show trace records generated
by stubs
* engine - show trace records generated by
engine
* parser - show trace records generated
by parser
* transport - show trace records generated by
transport
* noEntryExit - do not show entry/exit trace
records
The default filter is "stub;engine;parser;transport". So, for example, if I
wanted to enable client trace and show only transport trace records and no
entry/exit trace records, then the following would need to be specified:
ClientLogPath: /tmp/axis.log
LogFilter:transport;noEntryExit;
That it. In addition, I added methods to Axis class:
static int startTrace(const char* logFilePath, const char *logFilter=NULL);
static void stopTrace();
static void writeTrace(AXIS_TRACE_TYPE type, const char* functionName,
const char * fmt, ...);
So one can programmatically enable trace and write to the trace (this will
allow stub tracing in the future if we choose to add it). More information is
in the header file Axis.hpp.
Internally, I completely rewrote the AxisTrace class and added a slew of macro
to make adding trace points in the code very simple to do and elegant on the
eyes. For example, Trace entry and exit is simply done with the following
macros:
logEntryEngine("BasicTypeSerializer::BasicTypeSerializer")
logExit()
That it. The checks to determine whether trace is active is an inlined
function that checks a boolean, so performance should not be a consideration.
In addition, the check is done once within a method or function.
I do not trace parameters unless I fealt there is a need to. However,
currently, I do trace anything that is returned by a method or function via the
following macros:
#define logExit()
#define logExitWithReturnCode(lRC)
#define logExitWithInteger(lint)
#define logExitWithPointer(lPointer)
#define logExitWithString(lString)
#define logExitWithBoolean(lBoolean)
#define logExitWithMessage(lfmt)
A typical trace record will look like the following (following are entry exit
trace records)
[13/11/2008 15:55:55:509] 00007860 transport >
HTTPTransport::processHTTPHeader():
[13/11/2008 15:55:55:510] 00007860 transport <
HTTPTransport::processHTTPHeader():
It includes a timestamp, a thread ID, the component that is doing the trace, a
one character field indicating Trace type:
* > (entry)
* < (exit)
* X (exception)
* D (debug)
and the method/function name. After which there will be additional trace data.
With tracing enabled, you will know exactly where an exception is being thrown
from. A typical trace record for when an exception is thrown is as follows:
[13/11/2008 15:55:55:510] 00007860 transport X
HTTPTransport::readHTTPHeader(): Line=1851:
File=/home/amra/axis/L1.1.0/src/ws-axis/c/src/transport/axis3/HTTPTransport.cpp:
HTTPTransportException - SERVER_TRANSPORT_HTTP_EXCEPTION: Server sent HTTP
error: 'Not Found'
And finally, you can dump out the request/response messages by enabling
transport trace. Here is a sample:
[13/11/2008 15:55:55:280] 00007860 transport D HTTPChannel::writeBytes():
POST /axis HTTP/1.1
Host: 127.0.0.1:13260
Content-Type: text/xml; charset=UTF-8
SOAPAction: ""
Content-Length: 393
[13/11/2008 15:55:55:280] 00007860 transport < HTTPChannel::writeBytes():
Exit with integer value of 122
[13/11/2008 15:55:55:281] 00007860 transport > HTTPChannel::writeBytes():
[13/11/2008 15:55:55:282] 00007860 transport D HTTPChannel::writeBytes():
<?xml version='1.0' encoding='utf-8' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<SOAP-ENV:Body>
<ns1:div xmlns:ns1="http://soapinterop.org/wsdl";>
<ns1:arg_0_0>10</ns1:arg_0_0>
<ns1:arg_1_0>5</ns1:arg_1_0>
</ns1:div>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
.
.
.
[13/11/2008 15:55:55:508] 00007860 transport D HTTPChannel::readBytes():
HTTP/1.1 404 Not Found
Server: WebSphere Application Server/5.1
Content-Type: text/html;charset=UTF-8
Content-Language: en-GB
Transfer-Encoding: chunked
21
Error 404: File not found: null 0
[13/11/2008 15:55:55:509] 00007860 transport < HTTPChannel::readBytes(): Exit
with integer value of 203
This support has been put in CMVC under the following SVN revisions:
For visual C++ files: http://svn.apache.org/viewvc?view=rev&revision=713844
For external include files and build xml files:
http://svn.apache.org/viewvc?view=rev&revision=713843
For engine. parser, transport, channel files:
http://svn.apache.org/viewvc?view=rev&revision=713841
was (Author: nadiramra):
OK, finally got this done. Tracing is now integrated in the code so that
only one binary is needed when we put out a release. I have also disabled and
removed the previous support in which a tool was used to dynamically produce
source with a trace points. That was kludgy and introduced complexity when
trying to do tracing of the xml parser and transport, and channels. It is much
cleaner now. Here is the information on the support.
To enable tracing, simply set one of ClientLogPath or LogPath (for server
logging) to the path of the trace file in the axiscpp.conf file. With this
support, a new configuration variable, LogFilter, can be set to filter the
trace records so you can isolate a component. The filter is a semicolon
delimited string of possible filters. Possible filters include:
* stub - show trace records generated
by stubs
* engine - show trace records generated by
engine
* parser - show trace records generated
by parser
* transport - show trace records generated by
transport
* noEntryExit - do not show entry/exit trace
records
The default filter is "stub;engine;parser;transport". So, for example, if I
wanted to enable client trace and show only transport trace records and no
entry/exit trace records, then the following would need to be specified:
ClientLogPath: /tmp/axis.log
LogFilter:transport;noEntryExit;
That it. In addition, I added methods to Axis class:
static int startTrace(const char* logFilePath, const char *logFilter=NULL);
static void stopTrace();
static void writeTrace(const char* functionName, const char * fmt, ...);
So one can programmatically enable trace and write to the trace (this will
allow stub tracing in the future if we choose to add it). More information is
in the header file Axis.hpp.
Internally, I completely rewrote the AxisTrace class and added a slew of macro
to make adding trace points in the code very simple to do and elegant on the
eyes. For example, Trace entry and exit is simply done with the following
macros:
logEntryEngine("BasicTypeSerializer::BasicTypeSerializer")
logExit()
That it. The checks to determine whether trace is active is an inlined
function that checks a boolean, so performance should not be a consideration.
In addition, the check is done once within a method or function.
I do not trace parameters unless I fealt there is a need to. However,
currently, I do trace anything that is returned by a method or function via the
following macros:
#define logExit()
#define logExitWithReturnCode(lRC)
#define logExitWithInteger(lint)
#define logExitWithPointer(lPointer)
#define logExitWithString(lString)
#define logExitWithBoolean(lBoolean)
#define logExitWithMessage(lfmt)
A typical trace record will look like the following (following are entry exit
trace records)
[13/11/2008 15:55:55:509] 00007860 transport >
HTTPTransport::processHTTPHeader():
[13/11/2008 15:55:55:510] 00007860 transport <
HTTPTransport::processHTTPHeader():
It includes a timestamp, a thread ID, the component that is doing the trace, a
one character field indicating Trace type:
* > (entry)
* < (exit)
* X (exception)
* D (debug)
and the method/function name. After which there will be additional trace data.
With tracing enabled, you will know exactly where an exception is being thrown
from. A typical trace record for when an exception is thrown is as follows:
[13/11/2008 15:55:55:510] 00007860 transport X
HTTPTransport::readHTTPHeader(): Line=1851:
File=/home/amra/axis/L1.1.0/src/ws-axis/c/src/transport/axis3/HTTPTransport.cpp:
HTTPTransportException - SERVER_TRANSPORT_HTTP_EXCEPTION: Server sent HTTP
error: 'Not Found'
And finally, you can dump out the request/response messages by enabling
transport trace. Here is a sample:
[13/11/2008 15:55:55:280] 00007860 transport D HTTPChannel::writeBytes():
POST /axis HTTP/1.1
Host: 127.0.0.1:13260
Content-Type: text/xml; charset=UTF-8
SOAPAction: ""
Content-Length: 393
[13/11/2008 15:55:55:280] 00007860 transport < HTTPChannel::writeBytes():
Exit with integer value of 122
[13/11/2008 15:55:55:281] 00007860 transport > HTTPChannel::writeBytes():
[13/11/2008 15:55:55:282] 00007860 transport D HTTPChannel::writeBytes():
<?xml version='1.0' encoding='utf-8' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<SOAP-ENV:Body>
<ns1:div xmlns:ns1="http://soapinterop.org/wsdl";>
<ns1:arg_0_0>10</ns1:arg_0_0>
<ns1:arg_1_0>5</ns1:arg_1_0>
</ns1:div>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
.
.
.
[13/11/2008 15:55:55:508] 00007860 transport D HTTPChannel::readBytes():
HTTP/1.1 404 Not Found
Server: WebSphere Application Server/5.1
Content-Type: text/html;charset=UTF-8
Content-Language: en-GB
Transfer-Encoding: chunked
21
Error 404: File not found: null 0
[13/11/2008 15:55:55:509] 00007860 transport < HTTPChannel::readBytes(): Exit
with integer value of 203
This support has been put in CMVC under the following SVN revisions:
For visual C++ files: http://svn.apache.org/viewvc?view=rev&revision=713844
For external include files and build xml files:
http://svn.apache.org/viewvc?view=rev&revision=713843
For engine. parser, transport, channel files:
http://svn.apache.org/viewvc?view=rev&revision=713841
> enable axis c++ (engine) tracing
> --------------------------------
>
> Key: AXISCPP-100
> URL: https://issues.apache.org/jira/browse/AXISCPP-100
> Project: Axis-C++
> Issue Type: Wish
> Components: Trace Utility
> Affects Versions: future (enh)
> Environment: ALL
> Reporter: Aleksander Slominski
> Fix For: current (nightly)
>
>
> i think it would be good to have some kind of tracing/logging compiled into
> binary that could be triggered by setting environment variable (for example
> AXISCPP_TRACE=engine:ALL).
> it would be very useful tool when debugging such problems like wrong
> SOAPAction to see if engine received request and see where did it go and why
> it was rejected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
