The other thing that helps is turning logging on on ther server. I start the axis server with the following script...
set TUSCANY_SCACPP_LOGGING=9 set PATH= ... axis2_http_server.exe -l 4 So in the first instance what we need to do is work up all of these hints and tips into a step by step service construction/debugging guide. I think pete/andy already have words in this area so we should review and extend if required. Secondly we need to think, post M1, what we add to make life easier, for example C++2WSDL WSDL2C++ Specific logging of the points that cause problems Debug helpers What else should be on this list? On 6/27/06, Edward Slattery <[EMAIL PROTECTED]> wrote:
Having been working on the Windows build today, I agree with your summary. There might even be problems to less new users. My saviours this afternoon hav been: 1) Running the axis http server in the debugger - loading the extra sca_ws dll and setting breakpoints. 2) Checking very very carefully the env vars TUSCANY_SCACPP, TUSCANY_SDOCPP, TUSCANY_SCACPP_SYSTEM_ROOT. 3) Checking them again. 4) checking the logs in the axis logs directory - Calculator_blocking gives you what happens when the service is loaded. axis2.log tells you if the service didnt load. - I just asked the asix2c people to add some details to the log to say which dll in which path didnt load - then I think we have all bases covered. On 27/06/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > I've spent a little time playing with the C++ SCA implementation. I want > to > replay my understanding to see if it is correct. > > When constructing a service that will have a web service binding you have > to > provide a number of things including > > myservice.h to define the class that is the service > myservice.cpp to implement the class that is the service > myservice.wsdl to describe the service interface > > Of course you have to provide the appropriate SCA configuration files > also, > e.g. sca.module, Tuscany-model.config etc, and you have to SCAGen the > interface to generate proxies and wrappers. > > - At this point in time there is no WSDL -> C++ or C++ -> WSDL tooling > > Hence at present there is a requirement that you, as the developer of the > service, ensure that the interface described in C++ matches the interface > described in WSDL. > > - At this point in time there is no C++ SDO support for static types > > Hence interfaces to services that take SDOs will always descibe the > interface in terms of DataObjects. > > - The web services interfaces adopt the doc/literal/wrapped pattern > > Hence the WSDL has to be constructed/used carefully in this respect to > match > the expectations of the runtime and the types that are used to describe > WSDL > message elements are not the types that find their way in and out of the > C++ > service implementation. It is the types that are themselves wrapped that > find themselves presented to and returned from the service implementation. > > Is this understanding correct? > > Is there some way we can provide a helper function (or simple generator) > that demonstrates how a service operation should handle the types it is > presented with and produce a type for return based on the WSDL description > of the interface? This could be as simple as providing a mechanism to > print > out a template C++ operation based on the model formed from the WSDL. > Maybe > this could be done with good documentation and samples but I'm not sure. > > I sense that there will be mistakes made in this area by new users;-) > > Regards > > Simon > >
