I don't know anything about the server, but I do know about trace. You can get trace out of the server by setting LogPath to the trace file name in axiscpp.conf. The trace file need not exist previously. The release version of 1.5 does not have trace enabled, but you can download a traced version from http://cvs.apache.org/dist/axis/nightly/ which is the latest nightly build. Here are some words about client trace that I must put into the documentation. Server trace is the same except for the variable to set in axiscpp.conf. Axis C++ traces method names, parameters and environment data out to a file. Switch trace on in axiscpp.conf by setting ClientLog to the trace file name. The directory must exist but the file should not. For instance (on Windows) ClientLogPath:c:\axishome\AxisLog.taw. The trace file can have any name and any extension. AxisLog.taw is just an example. Trace files are human-readable but are better viewed using the Trace Analyzer for WebSphere, which can be downloaded from http://alphaworks.ibm.com/tech/ta4was. Runtime trace starts up after axiscpp.conf is read in. Startup starts at the very first call to Axis. Switch startup on by setting the environment variable AXISCPP_STARTUP_TRACE. Set AXISCPP_STARTUP_TRACE to the trace file name. For instance (on Windows) AXISCPP_STARTUP_TRACE=c:\axishome\AxisStartup.taw. Run the trace analyzer using java -jar traceanalyzer.jar AxisLog.taw. In the trace analyzer "Properties of the trace file" shows useful information about the user's environment and level of Axis. Here is an example few lines from a typical trace file... [12/03/2005 22:06:20:000] 1 > SOAPTransportFactory.initialize() [12/03/2005 22:06:20:000] 1 > AxisConfig.getAxisConfProperty() @00327058,[05000000] <....> [12/03/2005 22:06:20:000] 1 < AxisConfig.getAxisConfProperty() @00327058,@2 "C:\fvtests\src\ws-axis\c/../../../obj/package/Win32/bin/HTTPTransport.dll" [12/03/2005 22:06:20:000] 1 > SOAPTransportFactory.loadLib() [12/03/2005 22:06:20:000] 1 > -.callLoadLib() [69FFFFFF863200] <i.2.> [12/03/2005 22:06:20:000] 1 < -.callLoadLib() [00003800] <..8.> [12/03/2005 22:06:20:000] 1 < SOAPTransportFactory.loadLib() 0 [12/03/2005 22:06:20:000] 1 < SOAPTransportFactory.initialize() 0 Every line starts with a time/date stamp. Unfortunately Axis C++ does not currently support milliseconds or threadids. In the 3rd column > is a trace entry and < is a trace exit. In the 4th column is the Classname.methodname, indented to show the call stack. Where the classname is -, this is a C-style global function outside of any class. The rest of the data on each line are the parameters. The @00327058 shows that getAxisConfProperty is an instance method and 00327058 is the address of the AxisConfig instance ("this" pointer). This shows which instance of AxisConfig, getAxisConfProperty was invoked for. Methods whose "this" pointer is missing in the trace are static methods. SOAPTransportFactory::initialize is an example of a static method. Parameters are traced as a comma separated list. Control blocks and binary data (typedefs, #defines, etc) are traced like [05000000] <....> where the data as hex is between the [] and the data as ascii characters is between the <>. For a pointer to such data, the pointer is output before what the pointer is pointing at is traced. For void* pointers, the pointer and the first byte of the data is traced (there is no way of knowing the length of the data pointed at by a void* pointer). Most methods have only one return statement. AxisConfig::getAxisConfProperty has multiple return statements and the @2 on it's exit trace shows that it exitted from the 2nd return statement in that method. Here is a snippet from another trace file... [12/03/2005 22:06:05:000] 1 X HTTPTransport getBytes @00326180,@1 caught [40FFFFFFB138000000000000000000002DFFFFFF9055FFFFFF89FFFFFF944300350000003F00000032000000] <@8..........-U.C.5...?...2...> [12/03/2005 22:06:05:000] 1 > SoapBinInputStream.~SoapBinInputStream() @004350F0 [12/03/2005 22:06:05:000] 1 < SoapBinInputStream.~SoapBinInputStream() @004350F0 [12/03/2005 22:06:05:000] 1 > HTTPTransportException.getExceptionCode() @0012F7E0 [12/03/2005 22:06:05:000] 1 < HTTPTransportException.getExceptionCode() @0012F7E0,50 [12/03/2005 22:06:05:000] 1 > HTTPTransportException.what() @0012F7E0 [12/03/2005 22:06:05:000] 1 < HTTPTransportException.what() @0012F7E0,"HTTPTransportException:HTTP transport error Not Found" [12/03/2005 22:06:05:000] 1 X ClientAxisEngine process @00435638,caught AxisException(2, "HTTPTransportException:HTTP transport error Not Found") The X in the 3rd column shows that HTTPTransport has caught an exception. The @1 in it's parameter list shows that it is the first catch statement in that method that has caught the exception. getBytes does some work and then rethrows the exception, which ClientAxisEngine::process catches. Unfortunately the tool does not show the stack unwinding properly when exceptions are thrown and caught. Another snippet... [12/03/2005 22:06:05:000] 1 > SoapSerializer.serialize() @0032B5A0,------------> [12/03/2005 22:06:05:000] 1 I - " [12/03/2005 22:06:05:000] 1 I - <" In this example SoapSerializer::serialize is passed a string that contains a newline character, a < character and the null terminator. The ------------> indicates that multiline output follows. If a parameter is traced as <BADPOINTER> it means that trace attempted to dereference a pointer, which caused a SIGSEGV that trace caught. If a parameter is traced as <UNKNOWNTYPE, it means the trace tool and runtime have got out of step, which is a bug. If a parameter is traced as <ANONYMOUS> it means it is unnamed in the method signature. Interesting places to look in a trace include... - the entry trace for HTTPChannel::operator<< shows the message that will be sent on the wire - any exception records - the trace record immediately before ~Stub, since ~Stub is often called immediately after a SIGSEGV I hope this helps Mark Mark Whitlock IBM ----- Forwarded by Mark Whitlock/UK/IBM on 11/05/2005 15:54 ----- "Yampolsky, Robert" <[EMAIL PROTECTED] To com> "Apache AXIS C User List" <axis-c-user@ws.apache.org> 11/05/2005 15:33 cc Subject Please respond to RE: list of deployed web services "Apache AXIS C User List" Yes, I do have the files in the wsdls folder. I'm just trying to get it to display the wsdl for the standard services that come with the distribution (calculator, array, etc). Axis generates the service list page correctly when I access http://localhost/axis, and I looked at the code, which seems to be scanning the wsdls folder to generate that page, so they're definitely there. The code to process the ?wsdl URL's looks simple enough, but it's apparently segfaulting. I notice that this code has changed between versions 1.4 and 1.5. Anyway, for some reason Apache isn't generating a core dump (that I can find) when it segfaults. Is there a way to get axis to dump debugging info to a log. I see that there's a log file specified in the axiscpp_deploy/etc/axiscpp.conf file, but how do you turn on logging? Am I right in guessing that the following code from Axis.cpp in the 'engine' directory is what's supposed to list the wsdl file (the second 'else' clause)? Anybody see anything that could segfault there? // Handle the GET method else if (AXIS_HTTP_GET == pStream->getSubProtocol()) { // get the uri path // i.e "/abc/xyz/" part of http://somehost/abc/xyz/ string sUriWOAxis = pStream->getTransportProperty(SERVICE_URI); string sServiceName; bool bNoExt = true; if (sUriWOAxis == "/") { bNoExt = false; sUriWOAxis = ""; } if (sUriWOAxis.empty ()) { ...generate web page listing all deployed services. } else { sServiceName = g_pConfig->getAxisConfProperty(AXCONF_AXISHOME); sServiceName += WSDLDIRECTORY + sUriWOAxis + ".wsdl"; // Check whether wsdl file is available if ((WsddFile = fopen (sServiceName.c_str (), "r")) == NULL) { pStream->sendBytes("<h3>Url not available</h3>", NULL); Status = AXIS_SUCCESS; // Handle the error } else { int charcount = 0; while ((charcount = fread (ReadBuffer, 1, BYTESTOREAD - 1, WsddFile)) != 0) { *(ReadBuffer + charcount) = '\0'; pStream->sendBytes(ReadBuffer, NULL); } Status = AXIS_SUCCESS; fclose (WsddFile); } } } -----Original Message----- From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 10, 2005 11:39 PM To: Apache AXIS C User List Subject: RE: list of deployed web services Do you have the wsdl files in $AXISCPP_DEPLOY/wsdls folder? BTW, Simple Axis server does not support this ?wsdl URLs. It only works with Apache. Also note that, Axis C++ engine is not capable of generating the WSDL for the service. Rather it gives out the WSDL file stored in $AXISCPP_DEPLOY/wsdls folder. Thanks, Samisa... -----Original Message----- From: Yampolsky, Robert [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 10, 2005 9:52 PM To: Apache AXIS C User List Subject: RE: list of deployed web services Not true. The URL's in the front page have /axis in them (I'm using 1.5). Same thing happens when I click the front page links or type the URL's manually. I don't see any core files generated by the Apache segfault, so I can't determine why it's segfaulting. I tried to access a wsdl URL through simple_axis_server, but that just hangs (browser gets no response). Don't know if that's supposed to work, but I thought that if it did and it segfaulted, I'd stand some chance of debugging it. I'm assuming that the following in my httpd.conf file is all I need to do to map the localhost/axis path to the true axis location and that the axis handler is responsible for translating the ?wsdl to the wsdls subdirectory. LoadModule axis_module modules/libaxiscpp_mod2.so <Location /axis> SetHandler axis </Location> -----Original Message----- From: Tony Dodd [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 10, 2005 11:32 AM To: 'Apache AXIS C User List' Subject: RE: list of deployed web services It's simply got the wrong url coded in the Axis front page, if you look at Axis.cpp someone has commented out the line that adds /axis (line 235 in 1.4). If you enter http://localhost/axis/array?wsdl in the url combo explicitly it should work. Tony Dodd Oxford University Research Technologies (Xaira) >-----Original Message----- >From: Yampolsky, Robert [mailto:[EMAIL PROTECTED] >Sent: 10 May 2005 16:09 >To: Apache AXIS C User List >Subject: RE: list of deployed web services > >Doesn't work for me. http://localhost/axis does bring up a >page with links to all the wsdl's, but when I click on any of >those links I get a >503 error in my browser, and the Apache error log logs a >segfault. Any idea how to debug this? > >-----Original Message----- >From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] >Sent: Monday, May 09, 2005 11:56 PM >To: Apache AXIS C User List >Subject: RE: list of deployed web services > >Hi, > If you have the wsdl files in %AXISCPP_DEPLOY%\wsdls >folder, you should get the ?wsdl thing working. >http://localhost/axis/array?wsdl is the correct link (and it >works on my >machine) > >Also the calculator sample need three mandatory parameters: >calculator.exe add 101 10 > >HTH > >Samisa... > >-----Original Message----- >From: So Hok Chun, Bill [mailto:[EMAIL PROTECTED] >Sent: Monday, May 09, 2005 9:30 PM >To: axis-c-user@ws.apache.org >Subject: list of deployed web services > >Dear All, > >With some help from people in the mailing list, I installed axis. > >And I can run some of the samples like array, base, rpcfault >(but not calculator. I guess there should be some problem in >that sample). > >About the http://localhost/axis page, there's a column "WSDL" >in the table. The is like http://localhost/array?wsdl > >However, there's simply no such directory in my server. I >tried http://localhost/axis/array?wsdl . But still doesn't >work. The browser just return a blank page. > >What should the correct link look like? > >Thanks for your help. > >Yours, >Bill >
