Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 70017 invoked from network); 1 Mar 2006 16:15:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Mar 2006 16:15:54 -0000 Received: (qmail 5925 invoked by uid 500); 1 Mar 2006 16:16:37 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 5837 invoked by uid 500); 1 Mar 2006 16:16:37 -0000 Mailing-List: contact axis-cvs-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-cvs@ws.apache.org Received: (qmail 5826 invoked by uid 99); 1 Mar 2006 16:16:36 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Mar 2006 08:16:36 -0800 X-ASF-Spam-Status: No, hits=-9.4 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 01 Mar 2006 08:16:34 -0800 Received: (qmail 69601 invoked by uid 65534); 1 Mar 2006 16:15:26 -0000 Message-ID: <20060301161526.69592.qmail@minotaur.apache.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r382070 - in /webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp: arch/WSDL2Ws.ihtml arch/handler.ihtml arch/mem-management.ihtml clientuser-guide.ihtml install-guide.ihtml Date: Wed, 01 Mar 2006 16:15:24 -0000 To: axis-cvs@ws.apache.org From: dicka@apache.org X-Mailer: svnmailer-1.0.7 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Author: dicka Date: Wed Mar 1 08:15:23 2006 New Revision: 382070 URL: http://svn.apache.org/viewcvs?rev=382070&view=rev Log: Update Axis C++ documentation. Modified: webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/WSDL2Ws.ihtml webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/handler.ihtml webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/mem-management.ihtml webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/clientuser-guide.ihtml webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/install-guide.ihtml Modified: webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/WSDL2Ws.ihtml URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/WSDL2Ws.ihtml?rev=382070&r1=382069&r2=382070&view=diff ============================================================================== --- webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/WSDL2Ws.ihtml (original) +++ webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/WSDL2Ws.ihtml Wed Mar 1 08:15:23 2006 @@ -80,7 +80,7 @@

Wrapper classes for complex types with data members and constructors/destructors
Helper functions for serializing/deserializing complex types
Wrapper structs to handle arrays of complex types
Wrapper classes to handle arrays of complex types

@@ -90,7 +90,7 @@

2.1 Dependencies on Axis Java tool

Apache Axis C++ uses WSDL processing tools from Axis Java project and extends those for C/C++ code generation.

The following jar files that comes with (or used by) Axis Java are required to run Axis C++ WSDL2Ws tool:

The following jar files that come with (or used by) Axis Java are required to run Axis C++ WSDL2Ws tool:

axis.jar
wsdl4j.jar
saaj.jar

"SchemaUtils" (SchemaUtils.java) and "ElementDecl" (ElementDecl.java) classes of Axis Java tools have been overridden by Axis C++ WSDL2Ws implementation.

"SchemaUtils" and "ElementDecl" classes of Axis Java tools have been extended by Axis C++ WSDL2Ws implementation.

Other than the two classes mentioned above, no other class from Axis Java WSDL tool implementation has been overridden or extended at present by Axis C++ WSDL2Ws tool; hence all other classes in Axis Java tool are used as they are.

Except for "SchemaUtils" and "ElementDecl" classes, the rest of the classes of Axis C++ WSDL2Ws are unique to Axis C++ and they use functionality form Axis Java jars.

2.2 Building the Tool

If you want to build the WSDL2Ws tool form source, there is an Apache Ant build script to help you. +

If you want to build the WSDL2Ws tool from source, there is an Apache Ant build script to help you. Assuming that you have installed Ant properly, what you have to do is to set the CLASSPATH to include Axis Java jar files mentioned in the previous section and run ant command in $AXISCPP_HOME/src/wsdl folder. Once you build the tool the generated wsdl2ws.jar file would be placed in $AXISCPP_HOME/lib/axis/ folder.

@@ -124,10 +122,9 @@ -help, -h print a short help message
-o(folder) target output folder - default is current folder
-l(c++|c) target language (c++|c) - default is c++
--s(server|client) generate server skeletons or client stubs? (serve|client) - default is server
+-s(server|client) generate server skeletons or client stubs? (server|client) - default is server
-w(wrapped|nonwrapped) wrapping style of the WSDL (wrapped|nonwrapped) - default is wrapped
-verbose, -v be verbose
--m(none|gnu) generate make files (none|gnu) - default is none

@@ -147,9 +144,6 @@ set CLASSPATH=%AXISCPP_HOME%\lib\axis\wsdl2ws.jar;%CLASSPATH%

Alternatively, you can use the -classpath option of java command to specify the CLASSPATH.

- -

NOTE: It is a MUST that that you have wsdl2ws.jar from Axis C++ appearing before all the jar files form Axis Java on the CLASSPATH. If not you will run into trouble when generating code. This is a known problem and happens because the two classes, "SchemaUtils" and "ElementDecl", of Axis C++ that overides Axis Java classes with the same name have identical package names to that of Axis Java classes. -

2.5 Running the Tool

Modified: webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/handler.ihtml URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/handler.ihtml?rev=382070&r1=382069&r2=382070&view=diff ============================================================================== --- webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/handler.ihtml (original) +++ webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/handler.ihtml Wed Mar 1 08:15:23 2006 @@ -42,57 +42,45 @@

Building the echoStringHeaderHandler

Linux

The build files are available at

-<Axis install directory>/samples/server/echoStringHeaderHandler
-Change your current directory to this directory and then execute the -following... - +
The build files are available at:
+
<Axis install directory>/samples/server/echoStringHeaderHandler
+
Change your current directory to this directory and then execute the following...

make

make install

-

The handler libeshhandler.so file will be created at <Axis -install directory>/lib directory

Windows

The VC dsw file (ServerHandlers.dsw) is available at

<Axis Install directory>/vc/samples/server/ -ServerHandlers.dsw.

Open this file and build the project echoStringHeaderHandler. Once the build is successful you will find the DLL ( -echoStringHeaderHandler.dll) at<Axis install -directory>/bin

The handler libeshhandler.so file will be created at

<Axis install directory>/lib directory

Windows

The VC dsw file (ServerHandlers.dsw) is available at

<Axis Install directory>/vc/samples/server/ServerHandlers.dsw.

Open this file and build the project echoStringHeaderHandler. Once the build is successful you will find the DLL ( +echoStringHeaderHandler.dll) at:

<Axis install directory>/bin

Configuring the echoStringHeader Handler

Edit the server.wsdd file -(as +(as created when you configured your server ) to include the handler for a particular service.
-In this instance we are using the Calculator server example that we have used in both the client and server setup examples. The example below shows how a linux file would look e.g. libeshhandler.so is used please vary the file according to the libraries you have created. This example shows the handler being deployed on both the incoming and outgoing message. +In this instance we are using the Calculator server example that we have used in both the client and server setup examples. The example below shows how a linux file would look e.g. libeshhandler.so is used please vary the file according to the libraries you have created. This example shows the same handler being deployed on both the incoming and outgoing message. -

<service name="Calculator" provider="CPP:RPC" description="Simple Calculator Axis C++ Service ">
-
-<requestFlow name="CalculatorHandlers">
-<handler name="ESHHandler" type="<Axis installation -directory>/handlers/custom/echoStringHeaderHandler/libeshhandler.so"> -
-</handler>
-</requestFlow>
-<responseFlow name="CalculatorHandlers">
-<handler name="ESHHandler" type="<Axis installation -directory>AXISCPP_DEPLOY/lib/libeshhandler.so">
-</handler>
-</responseFlow>
-
-<parameter name="allowedMethods" value="add sub mul div "/>
-<parameter name="className" value="<Axis installation -directory>/webservices/libcalculator.so" />
-</service>
- +

<service name="Calculator" provider="CPP:RPC" description="Simple Calculator Axis C++ Service">
+  <requestFlow name="CalculatorHandlers">
+    <handler name="ESHHandler" type="<Axis installation directory>/handlers/custom/echoStringHeaderHandler/libeshhandler.so">
+    </handler>
+  </requestFlow>
+  <responseFlow name="CalculatorHandlers">
+    <handler name="ESHHandler" type="<Axis installation directory>/handlers/custom/echoStringHeaderHandler/libeshhandler.so">
+    </handler>
+  </responseFlow>
+  <parameter name="allowedMethods" value="add sub mul div"/>
+  <parameter name="className" value="<Axis installation directory>/webservices/libcalculator.so" />
+</service>

@@ -105,7 +93,7 @@

Running the echoStringHeader Handler

Since this Handler is configured to the Calculator web service in the above step, this Handler will be executed when a client sends a SOAP -request to the Calculator web service. Use the calculator +request to the Calculator web service. Use the calculator client you created earlier.

@@ -116,26 +104,22 @@

Building the testHandler

The build files are available at -<Axis installation directory>/samples/client/testHandler. Change your current directory to this direcotory and then you could execute the following. +<Axis installation directory>/samples/client/testHandler. Change your current directory to this directory and then you can execute the following.

linux

+
Linux

make

make install

-

The handler so file will be created at <Axis -installation directory>/lib/
-

windows

The VC dsw file (ClientHandlers.dsw) is available at <Axis -Installation directory>/vc/samples/client/ClientHandlers.dsw.Open this file and -build the project TestHandler.

Once the build is successful you will find the DLL -testHandler.dll) at <Axis Installation directory>/bin. If you see this DLL at the above -location you are done with the first step.

The handler so file will be created at

<Axis installation directory>/lib/

Windows

The VC dsw file (ClientHandlers.dsw) is available at:

<Axis Installation directory>/vc/samples/client/ClientHandlers.dsw

Open this file and build the project TestHandler.

Once the build is successful you will find the DLL (testHandler.dll) at: +

<Axis Installation directory>/bin

If you see this DLL at the above location you are done with the first step.

Configuring the testHandler

@@ -148,14 +132,12 @@ Up until this point you did not need a client wsdd file the client only requires a wsdd file when it has handlers.

<service name="Calculator" provider="CPP:RPC" -description="Calculator web service">
-<requestFlow name="CalculatorHandlers">
-<handler name="TestHandler" -type="<Axis Installation directory>/lib/libtest_client_handler.so">
-</handler>
-</requestFlow>
-</service>

<service name="Calculator" provider="CPP:RPC" description="Calculator web service">
+  <requestFlow name="CalculatorHandlers">
+    <handler name="TestHandler" type="<Axis Installation directory>/lib/libtest_client_handler.so">
+    </handler>
+  </requestFlow>
+</service>

@@ -164,14 +146,14 @@
Note: If you are using Client side Handlers you need to enter the ClientWSDDFilePath entry in your axiscpp.conf configuration file.
+ href="../install-guide.html#Installing_Client">axiscpp.conf configuration file.

Running the testHandler

Since this Handler is configured to the Calculator web service in the above step, this Handler will be executed when you run the calculator + href="../clientuser-guide.html#Generating_and_using_client_stubs">calculator web service client..

Modified: webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/mem-management.ihtml URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/mem-management.ihtml?rev=382070&r1=382069&r2=382070&view=diff ============================================================================== --- webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/mem-management.ihtml (original) +++ webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/arch/mem-management.ihtml Wed Mar 1 08:15:23 2006 @@ -1,111 +1,194 @@ - + Axis C++ Memory Management Guide - +

-

-Axis C++ Memory Management Guide

-
1.0 Version -
Feedback: axis-c-dev@ws.apache.org -

-Contents

-Introduction -
Allocation/De-allocation Semantics -
Dealing with SOAP Headers -
Open Issues +

Axis C++ Memory Management Guide

1.0 Version

Feedback: axis-c-dev@ws.apache.org

+ +

Introduction
+Allocation/De-allocation Semantics
+Dealing with SOAP Headers
+Windows Issues

Introduction

This guide records the memory management semantics and some of the rationales of the design decisions on which memory management semantics are based on. Being a C/C++ application, it is a must that all users as well as developers have a clear understanding on how to deal with memory allocation and deallocation. -

The allocation and deallocation mechanisms are centered around the serializer and deserializer operations in Axis C++. At the moment, because Axis C++ support both C and C++ clients and services, the deserializer uses malloc() for memory allocation. Hence C++ users may have to live with free() (instead of delete) for deallocation. Of course one could still use delete from C++ programs, however this may not guarantee the cleanest memory deallocation. - -

Allocation/De-allocation Semantics

Parameters

-On the server side all the parameters added to the serializer are de-allocated by the Axis Engine after serializing. Hence the user would not have to destruct the parameters to a function call after calling the function. - -On the client side, the user is responsibe for deallocating memory after a function call. -Please have a look at the base sample ($AXIS_HOME/samples/client/interoptests/base/) for a client side sample. - -Axis C++ does not provide a special function for dynamic allocation of objects. -One can select his/her own allocation mechanism. (malloc() in case of C programs and/or new in case of C++ programs) - -

Other Objects

-For XML elements and attribute objects that are created by IHandlerSoapSerializer, HeaderBlock and Attribute, the rules for deleting the objects when the request or response is processed are as follows. -

Any outbound objects created, either by a client application or by a handler, must be managed by the creator him(her)self. The Axis C++ engine does not delete any objects (HeaderBlocks, Attributes, BasicNodes etc.).
Any inbound objects that are created by the Axis C++ Engine as a result of deserialization should be deallocated by a target handler or the client application. Axis C++ Engine deallocates only the headerblocks that will remain in the deserializer (headerblocks with no target handler).

- -

Return Values

The values returned by the Axis C++ engine must be memory cleaned by the user written code. -The C++ code generated by the WSDL2Ws tool does contain destructors. However, at the moment, it is not gauranteed that the destructor of a generated class would clean all the pointer members (Some members are cleaned while others are not). Hence the users must have a look at the generated code to understand the semantics of memory cleaning. In case of C code, of course the user must take care of memory cleaning. -

Please note that in case of arrays, both for C and C++, the Axis C++ engine returns a struct. Hence it is a must that the memory is cleaned properly. -
C++ Example:
-

-        // testing echoIntegerArray
-        xsd__int_Array arrint; // Parameter for method call
-        arrint.m_Array = new int[ARRAYSIZE];
-        arrint.m_Size = ARRAYSIZE;
-        
-	for (x = 0; x < ARRAYSIZE; x++)
-        {
-            arrint.m_Array[x] = x;
-        }
-        
-	printf ("invoking echoIntegerArray...\n");
-        
-	xsd__int_Array arrintResult = ws.echoIntegerArray (arrint);
-        
-	// Deal with the return value
-	if (arrintResult.m_Array != NULL)
-        {
-            printf ("successful\n");
-            // Clean memory of the returned array
-            free(arrintResult.m_Array);
-        }
-        else
-            printf ("failed\n");
-
-        // Clean memory allocated for parameter
-        delete [] arrint.m_Array;
-

-
Please have a look at the base sample ($AXIS_HOME/samples/client/interoptests/base/) for more information. +

Memory management is very important and if not handled correctly, +will quickly consume resources and slow down your application. The basic rules are;-

For client applications,

Any memory object that is created by the client to pass to a web service must be deleted by the client.
Any memory object that is passed back from the web service must be deleted by the client.

For server applications,

Any memory object that is passed to the service from the engine must be deleted by the service.
Any memory object that is created by the service and handed back to the engine will be deleted by the engine (or generated wrappers).

Within the client or service applications, all memory object must be +created using 'new' and deleted using 'delete' (The C style memory functions +'malloc' and 'free', or any of their variants must not be used).

+ +

new/delete Semantics

If you are using the wrappers produced by WSDL2Ws then a lot of the +memory management is handled for you within the generated code. You +still have to follow the rules for client or service, but there may be some +additional steps that you will have to follow.

+ +

Input Parameters

The following examples rely on the application is using the stubs generated +by the WSDL2Ws tool. If the user needs to use the Axis API directly, it is +assumed that they know what methods to call and how these methods have been +bundled by the generated code.

+ +

Simple Types

If the object is not nillable, then use the basic type. For example, if +the web service requires an xsd__byte value, then the client/service code would +be as follows;-

webService->asNonNillableElement( (xsd__byte) 127)

If the object is nillable, then use a pointer to the basic type. For +example, if the web service requires a pointer to a xsd__byte value, then the +client/service code would be as follows;-

xsd__byte * pNillableInput = new xsd__byte();

+*(pNillableInput) = (xsd__byte) 123;


+webService->asNillableElement( pNillableInput);


+delete pNillableInput;

Notice that once the client/service code no longer requires the +pNillableObject object, it is deleted (and must be deleted by the +client/service code).

+ +

Arrays and Complex Types

Arrays and Complex Types are treated as nillable, even if they are not. +For example, if the web service requires an array of xsd__byte values, +then the client/service code would be as follows;-

// Need an xsd__byte array of 2 elements,

+// each element is assigned the value 123.

+int arraySize = 2;

+xsd__byte ** array = new xsd__byte*[arraySize];

+for ( int inputIndex = 0 ; inputIndex < arraySize ; inputIndex++ )

+array[inputIndex] = new xsd__byte( 123);


+// Now copy this array into the xsd__byte_Array

+// that will be used to pass to the web service.

+xsd__byte_Array arrayInput;

+arrayInput.set( array, arraySize);


+// Call the web service.

+webService->asArray( &arrayInput);


+// Clear up input array

+for ( int deleteIndex = 0 ; deleteIndex < arraySize ; deleteIndex++ )

+{

+    delete

+    array[deleteIndex];

+}

+delete [] array;

Which is exactly the same code as would be used if the array was not nillable.

Output Parameters

+ +

Simple Types

If the returned object is not nillable, then use the basic type. For +example, if the web service returns a xsd__byte value, then the client/service +code would be as follows;-

xsd__byte result = webService->asNonNillableElement( (xsd__byte) 127);

If the object is nillable, then use a pointer to the basic type. For +example, if the web service returns a pointer to a xsd__byte value, then the +client/service code would be as follows;-

xsd__byte * pNillableOutput = webService->asNonNillableElement( (xsd__byte) 127);

+delete pNillableOutput;

Notice that once the client/service code no longer requires the +pNillableOutput object, it is deleted (and must be deleted by the client/service code).

+ +

Arrays and Complex Types

Arrays and Complex Types are treated as nillable, even if they are not. +For example, if the web service returns an array of xsd__byte values, then +the client/service code would be as follows;-

// Call the web service.

+xsd__byte_Array * arrayOutput = webService->getArray();


+// Retrieve the information within the array.

+int byteArraySize = 0;

+const xsd__byte ** byteArray = arrayOutput->get( byteArraySize);


+// Clear up output array
+delete arrayOutput;

Which is exactly the same code as would be used if the array was not +nillable. Notice that only the arrayOutput object (that is returned + by the web service) needs to be deleted. The byteArray object is a + pointer to the contents of the arrayOutput object so must not be + deleted.

Dealing with SOAP Headers

From Stubs

IHeaderBlock is a virtual class that defines the interface to deal with SOAP headers. You can create an IHeaderBlock at the client side using the API provided with Stub classes.
-

-IHeaderBlock* Stub::createSOAPHeaderBlock(AxisChar * pachLocalName, AxisChar * pachUri);
-

-Here the Stub class will maintain a list of all the created Header Blocks, and in the destructor of the Stub class, it will clean up memory by deleting all those Header Blocks that were created by the user. - -

Note 1: It is advisable that if a user wants to delete a Hheader Block, (s)he uses the API provided by the Stub class to do so.
-

-void deleteCurrentSOAPHeaderBlock();
-

-Stub class is also equipped with iterator methods to traverse through the current list of Header Blocks created. -
- -

Note 2: IHeaderBlock destructor will take care of the Header Block member variables and cleans them; BasicNodes (i.e its children) and the Attributes.
+

IHeaderBlock is a virtual class that defines the interface to deal with SOAP headers. +To create an IHeaderBlock in the client application, use the API provided with Stub classes, +i.e. ;-

> +

IHeaderBlock * Stub::createSOAPHeaderBlock( AxisChar * pachLocalName, AxisChar * pachUri);

The Stub class methods that handle header blocks keeps a list of all the created + header blocks. When the destructor is called, it will clean up memory + by deleting the header blocks that were created using the + cerateSOAPHeaderBlock method.

Note 1: The client/service + application must use the appropriate Stub method to delete a header block, + i.e. ;-

void deleteCurrentSOAPHeaderBlock();

+ +

Note 2: The IHeaderBlock destructor will take care of the header block member variables +(for example, BasicNodes may have children and attributes. These will be +deleted when the parent is deleted.).

From Handlers

If the Header Blocks are created within a Handler then it is the responsibility of the Handler writer to clean those. For that the user can write the cleanup code either in the fini() method or in the destructor of the Handler, depending on the following situations +

If header blocks are created within a 'Handler' then it is the responsibility of the +'Handler' writer to delete them. The deletion would occur in the 'clean-up' code either in the fini() +method or in the destructor of the Handler, depending on the following rules;-

If it is a session handler which needs to maintain its state, then the cleanup has to be done in the destructor.

If it is a request type handler the clean up can be done in the fini() mehtod of the Handler. Here the writer has to explicitly write the clean up code.

If it is a Session Handler which needs to maintain its state, then the cleanup has to be done in the destructor.

If it is a request type handler the clean up can be done in the fini() method of the Handler.

If a target handler access a header block created by the de-serializer then it is the responsibility of the Handler to delete it.

If a target handler access a Header Block created by the deserializer then it is the responsibility of the Handler to delete it. - -

Open Issues

When an array is de-serialized it uses C style memory re-allocation mechanism in the present code. C++ does not support realloc() and if we use new instead we have to allocate fresh memory blocks each time we need to increase the array size. This can be more expensive than using realloc(). Again the price paid for efficiency is that one has to use free() and not delete [] from C++ code. - +

Windows Issues

For Windows platforms, everything must built with the compiler flag '/MD' +regardless whether it is a DLL or an EXE. There are still problems however +when passing objects over process boundaries. If an object is created in +one process (say the Axis engine DLL) and then passed to another (say the client +application) then when the client tries to delete that object, it cannot find it +on its own process heap and throws an exception. This is because the +client process does not own the memory object. To overcome this problem, +on the process boundary, the original object is cloned (the clone uses the +client heap) and then the original object is freed from the engine heap. +Here is an example taken from the wrapper code created by WSDL2Ws from the +Arrays unit test (Arrays.cpp);-

xsd__int_Array * Arrays::simpleArray( xsd__int_Array* Value0)

+{

+   xsd__int_Array * RetArray = new xsd__int_Array();

+   :

+   :

+   if ( AXIS_SUCCESS == m_pCall->invoke())

+   {

+      if ( AXIS_SUCCESS == m_pCall->checkMessage( "simpleArrayResponse", "http://org.apache.axis/Arrays/"))

+      {

+         Axis_Array * RetAxisArray = m_pCall->getBasicArray( XSD_INT, "simpleType", 0);

+         RetArray->clone( *RetAxisArray);

+         Axis::AxisDelete( (void*) RetAxisArray, XSD_ARRAY);

+      
+}
   }

+   m_pCall->unInitialize();
+
   return
+RetArray;

+}

The two lines of interest are the cloning of the memory object (RetAxisArray +exists within the engine heap) into the RetArray memory object (that exists +within the client heap) and then the deletion of the RetAxisArray by calling the +AxisDelete method (which exists within the engine process and hence will be able +to delete the object from that heap).

- - + \ No newline at end of file Modified: webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/clientuser-guide.ihtml URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/clientuser-guide.ihtml?rev=382070&r1=382069&r2=382070&view=diff ============================================================================== --- webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/clientuser-guide.ihtml (original) +++ webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/clientuser-guide.ihtml Wed Mar 1 08:15:23 2006 @@ -39,10 +39,10 @@

Firstly copy the Calculator wsdl to the client samples directory e.g. (linux)

cd <Axis installation directory>/samples/client/calculator

cp -f <Axis installation directory>/wsdls/Calculator.wsdl ./

IMPORTANT:In this example we are showing you how to use the WSDL2Ws tooling to generate the stubs using +

IMPORTANT:In this example we are showing you how to use the WSDL2Ws tooling to generate the stubs using Calculator.wsdl. However, in the <Axis installation directory>/samples/client/calculator folder you will already find generated files. If you wish to use those without generating new ones you can do so. We recommend that you run the calculator sample with the -already generated files firstly and later practice using the tooling with Calculator.wsdl.
+already generated files firstly and later practice using the tooling with Calculator.wsdl.

Next you create the client-side stubs that represent the Calculator service.

Note: Don't forget to add all of the pre-requisite jar files into your classpath Modified: webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/install-guide.ihtml URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/install-guide.ihtml?rev=382070&r1=382069&r2=382070&view=diff ============================================================================== --- webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/install-guide.ihtml (original) +++ webservices/axis/trunk/site/src/cpp/src/documentation/content/xdocs/cpp/install-guide.ihtml Wed Mar 1 08:15:23 2006 @@ -47,7 +47,7 @@ Axis C++ needs an XML parser to parse SOAP messages and WSDD files. It has a parser abstraction layer that helps users to select/switch between -parsers. However only one parser library could be used at a time. +parsers. However only one parser library can be used at a time. Currently Xerces parser is supported by Axis C++.

Server only

@@ -67,7 +67,9 @@

Download Axis C++ binary distribution and extract the package into a directory of your choice.

2. Configure environment variables

2. Install Xerces C++ (2.2.0)

See the Xerces parser's documentation for installation instructions.

3. Configure environment variables

set AXISCPP_DEPLOY

AXISCPP_DEPLOY="Path to the folder where you installed Axis C++
@@ -79,7 +81,7 @@ PATH=<xerces installation directory>/bin;%AXISCPP_DEPLOY/bin%;%PATH%

Linux:
LD_LIBRARY_PATH="<xerces installation directory>/lib:$AXISCPP_DEPLOY/lib:$LD_LIBRARY_PATH"

3. Set Engine Wide Settings in Configuration File

4. Set Engine Wide Settings in Configuration File

Axis C++ uses a configuration file to let the user specify preferences such as log file locations, transport and parser libs to be used and location of deployment descriptor files.
@@ -92,6 +94,7 @@ Configuration file has the following syntax on the client-side:

The comment character is '#'
Transport_http - HTTP transport library: Required
Channel_HTTP - Channel transport library: Required
+Channel_HTTP_SSL - SSL channel transport library: Optional - only required is you are going to use ssl
XMLParser - The Axis XML parser library that comes with your configuration: Required
SecureInfo: SSL configuration information: Optional - only required if you are going to use ssl
ClientWSDDFilePath - Path to the client wsdd: Optional - only required if you are using client-side handlers
ClientLogPath - Path to the Axis C++ client log: Optional - only required if you want engine trace for debugging purposes

@@ -99,9 +102,9 @@

 
-Transport_http:/usr/local/axiscpp_deploy/lib/libaxis3_transport.so
-Channel_HTTP:/usr/local/axiscpp_deploy/lib/libaxis3_transport_channel.so
-XMLParser:/usr/local/axiscpp_deploy/lib/libaxis_xercesc.so
+Transport_http:/usr/local/axiscpp_deploy/lib/libhttp_transport.so
+Channel_HTTP:/usr/local/axiscpp_deploy/lib/libhttp_channel.so
+XMLParser:/usr/local/axiscpp_deploy/lib/libaxis_xerces.so
 ClientWSDDFilePath:/usr/local/axiscpp_deploy/etc/client.wsdd
 ClientLogPath:/usr/local/axiscpp_deploy/log/AxisClientLog

Once you have completed the above steps you should be ready to create and run your client application using AXIS C++ !
@@ -195,7 +198,7 @@ LoadModule axis_module libexec/libaxiscpp_mod.so

7. Deploying Axis Module to Apache Web Server

8. Deploying Axis Module to Apache Web Server

Now we need to copy Apache module (libaxiscpp_mod2.so - linux names- for Apache 2.0.x and libaxiscpp_mod.so for Apache 1.3.x) to the correct places and start Apache web server. @@ -216,7 +219,7 @@ To deploy with Apache 1.3.x

sh deploy_apache.sh -

8. See Axis C++ in action

9. See Axis C++ in action

Now the installation is complete. You can verify that the server side is working by accessing the URL http://localhost/axis using your web browser. You should get the Axis C++ welcome page and this page will show you a list of deployed services as specified by the <Axis Installation directory>/conf/server.wsdd file. Although at this stage you won't have any services deployed yet.

Now you can