Gsoap multiple wsdl files

This option specifies a proxy host name and port number with proxy credentials to connect to web sites through a proxy server.

This option can also be used to specify credentials to access a web site that requires authentication HTTP basic or digest authentication. This member points to the soap context that manages the instance, when the instance was allocated by the gSOAP engine. This option specifies an alternate file or path for typemap. See typemap. Union members are used to represent xsd:choice of elements. With this option, wsdl2h removes the union and replaces it with pointer members to produce a simpler structure:.

The last parameter of a service operation declared as a function in the interface header file is the response parameter. When multiple response parameters are returned by the service operation or if the response parameter is a complexType a struct or class , then the parameters should be wrapped in a special "response struct". However, if a single response parameter is a primitive type value then this parameter does not need to be wrapped in a response struct.

This option consistently wraps response parameters in a response struct, even when a single response parameter is a primitive type value. A part name associated with a type is implicitly qualified by the targetNamespace of the WSDL but may also be associated with the namespace of the type. The generated interface header file declares a wrapper for the Name request message and the Info response message:. Here, Name belongs to the ns1 namespace, i.

Now both Name and Info belong to the ns1 namespace, i. The elements Name and Record are the actual message names, qualified by the schema's targetNamespace:. This option adds typedef synonyms for structs and enums to the interface header file, which is useful for C source code.

A typedef synonym for a struct is declared by typedef struct name name; and for an enum is declared by typedef enum name name;.

The typemap. The i and s prefixes are declared such that the header file output by wsdl2h uses these prefixes instead of the default ns1 , ns2 , etc. It is strongly recommended to name the prefixes in this way, because future runs of wsdl2h may result in a different assignment of the default ns1 , ns2 , Therefore, it is recommended that application code should not rely on the default prefixes.

These type bindings have four parts:. When a type binding requires only the usage to be changed, the declaration part can be an ellipsis This method is useful to serialize types dynamically, when XML elements carry the xsi:type attribute indicating the type of element content.

The following illustrates an "any" type mapping for the ns:sometype XSD type in a schema. This type will be replaced with a "any" type wrapper that supports dynamic serialization of element types indicated by the xsi:type attribute:.

Additional members can be specified to extend a generated struct or class. Class and struct extensions are of the form:. For example, to use std::list as the container in the wsdl2h-generated declarations we add the following line to typemap.

Also a Qt container can be used instead of the default std::vector , for example QVector :. To remove containers, use wsdl2h -s. This also removes std::string , but you can re-introduce std::string with. The soapcpp2 tool is invoked from the command line and optionally takes the name of a header file as an argument or, when the file name is absent, parses the standard input:.

The soapcpp2 tool produces the XML data binding implementation source code, client-side stub functions, and server-side skeleton functions. If client and service applications are to be developed for the same Web services API then the same interface header file can be used to generate the source code for both the client and the service.

The new header file generated by this approach will not be identical to the original header file. The soapClientLib. The serialization functions are declared static to avoid link symbol conflicts. For this approach to compile, we also should create a separate interface header file env. By default all XML namespaces are included with the root element, which improves messaging performance at the sending and receiving sides, because a stack of xmlns binding scopes does not need to be maintained.

This is slower but may or may not reduce the message size. This option forces SOAP 1. In addition, the soapcpp2 tool saves the SOAP 1. This option serializes byte arrays specified as char91355 as strings.

Without this option char91355 is serialized as an array of bytes. Fixed-size arrays specified in the interface header file input are generally serialized as arrays in XML using item elements. This option restricts soapcpp2 to generate client-side source code only. When this option is combined with soapcpp2 -CS option -S , no client and server source code is generated.

For a serializable type T declared in the interface header file for soapcpp2, option -Ec generates:. For a serializable type T declared in the interface header file for soapcpp2, option -Ed generates:. For a serializable type T declared in the interface header file for soapcpp2, option -Et generates:. This option splits the serialization source code saved to soapC. This option alleviates compilation issues with very large source code files. By default without this option, soapcpp2 generates sample XML messages with the proper XML structure but without useful data.

The Test Messenger tool generates random messages directed by the template parameters included by soapcpp2 -g option -g. This option only has effect when soapcpp2 -x option -x is not used, which skips the generation of sample messages. This option specifies one or more directory paths to search for imported interface header files. Multiple paths are separated by a colon. This searches path1 and then path2 for files that are imported with import in file. By contrast, soapcpp2 -j option -j allows a soap context to be used and reused for multiple proxy and server instances.

By contrast to soapcpp2 -i option -i , this option allows a soap context to be used and reused for multiple proxy and server instances. This option skips the generation of the soapClientLib and soapServerLib files.

These files are generally not needed to build client and server applications. These files are useful to compile multiple "libraries" of client and server applications, such that all serialization source code is declared static and kept hidden from the global scope, which makes the serialization functions inaccessible to the global scope to prevent global name clashes. This option is experimental and should only be used to generate source code for modules.

This option is auto-enabled when a module directive is found in an interface header file for soapcpp2, see how to build modules and libraries with the module directive. This option is useful to prevent name clashes when soapcpp2 is invoked multiple times to generate source code for different parts of an application.

This option saves source code files with the specified file name prefix name with soapcpp2 -p name instead of soap as the file name prefix. When the main application is build from the renamed name -prefixed source code files, plugins and custom serializers that are compiled and linked with the application should include nameH.

The source code files are saved with name as prefix instead of soap. This means that all plugins and custom serializers that are compiled and linked with the application should include nameH. See also soapcpp2 -Q name option -Q name. This interface header file format is generated with wsdl2h -q name option -q name. This option generates a soapReadme. This option restricts soapcpp2 to generate server-side source code only. When this option is combined with soapcpp2 -CS option -C , no client and server source code is generated.

This option generates client-side stub functions and proxy classes, server-side skeleton functions and service classes with strict XML validation checks enabled. This option generates server auto-test source code. The generated source code implements a test server soapTester. See generating an auto test server for client testing for more details.

The import directive is used to include interface header files into other interface header files for soapcpp2. By contrast, the include directive and define directive for that matter is moved by the soapcpp2 tool into the generated source code file soapStub , see Section The include and define directives.

The import directive is used for two purposes: we use it to include the contents of one interface header file into another interface header file and to import a module, see Section How to build modules and libraries with the module directive. The include and define directives are copied by the soapcpp2 tool into the generated source code.

These directives are added to the top of the generated soapStub. Therefore, include and define directives can be used to influence the generated source code files. This example also uses an include and a define directive that will be added to the top of soapStub. A service operation is specified as a function prototype in an interface header file for soapcpp2.

For the function prototypes specified, the soapcpp2 tool generates client stub functions to invoke remote services and generates server skeleton functions to implement services. A single output parameter is specified and multiple output parameters should be wrapped in a struct or class, see Section Service operation parameter passing.

By convention, the response element name is the method name ending in Response. See Section Service operation parameter passing on how to change the declaration if the service response element name is different. The soapcpp2 tool generates a client stub function for the service operation. This stub is of the form:. The soapcpp2 tool generates a skeleton functions for the service operation. These classes have methods corresponding to the service operations, which on the client side can be invoked to invoke remote service operations and on the server side are implemented by the service application to execute the service operations.

The input parameters of a service operation must be passed by value or by pointer. Input parameters cannot be passed by reference. Passing a pointer to the data is preferred when the size of the data of the parameter is non trivial such as values of primitive type.

The input and output parameter types must be serializable, which means that there are some limitations on the types of data that can be passed, see Section Limitations. If the output parameter is a pointer or reference to a struct or class type, it is considered a service operation response element instead of a simple output parameter value. That is, the name of the struct or class is the name of the response element and the struct or class members are the output parameters of the service operation, see also Section How to change the response element name.

Therefore, if the output parameter has to be a struct or class , a response struct or class must be declared to wrap that struct or class type parameter. Likewise, if a service operation returns multiple output parameters then a response struct or class should be used to wrap the output parameters. The choice of name for anyname has no effect on the SOAP encoding and decoding and is only used as a place holder for the response.

The namespace URI is a unique identification that can be associated with the service operations and data types. The namespace URI disambiguates potentially identical service operation names and data type names used by disparate organizations. XML element names are XSD NCNames non-colon names that may contain letters, digits, underscores, hyphens, dots, and other special characters except reserved characters and colon. Trailing underscores in an identifier name are stripped from the XML encoding.

For example, return may be used as an XML element. By default the soapcpp2 tool generates data binding source code in which all local XML elements are and attributes are unqualified:. You can also use "elementForm" and "attributeForm" directives to un qualify local element and attributes, respectively.

An alternative to the prefix convention is the use of "colon notation" in the interface header file for soapcpp2. The colon notation for type names, struct and class names, and members overrides the prefix qualification rules explicitly:. The xsi:type member is an XML attribute in the xsi namespace. The soapcpp2 tool generates data binding implementation source code with the following cleaned-up struct without the annotations:.

The soapcpp2 tool also generates XML schemas with element and attribute references. That is, y:name is referenced from the y schema by the x:record complexType defined in the x schema. The colon notation also allows you to override the element and attribute forms to unqualified for qualified schemas:. Note that the use of colon notation to bind namespace prefixes to type names typedef, enum, struct, and class names translates to code without the prefixes.

This means that name clashes can occur between types with identical unqualified names:. The scope operator cannot be used in places where we need colon notation, such as struct and class member members. The default mechanism that associates XML tag names with the names of struct and class member members can be overridden by "re-tagging" names with the annotation of a tag placed next to the member member name.

This is particularly useful to support legacy code for which the fixed naming of member members cannot be easily changed. Tags will be namespace qualified as per schema element and attribute forms, unless preceded by a colon. As of gSOAP 2. After invoking the soapcpp2 tool on an interface header file description of a service to generate soapStub , soapH.

For C we use soapcpp2 -c option -c to generate C source code that is compiled with:. Depending on your system configuration, such as with Unix, linking with -lsocket , -lxnet , and -lnsl may be required. The myclient. To test client applications using an auto-generated echo test server, use soapcpp2 -T option -T , see the next section.

The myserver. Furthermore, an echo test server application soapTester. Compile this with:. The soapcpp2 -T option -T generates an echo test server application source code soapTester.

The feature also supports C source code, use the soapcpp2 -c -T options -c and -T to generate a C test server. The echo test server can be used to test a client application, by the client sending messages to the echo test server that echos responses back to the client.

These responses are structurally valid but may lack sufficient details to consider the response messages useful. This starts an iterative stand-alone server on port The data in the response messages are copied from the request messages when possible, or XML default values, or empty otherwise.

The soapcpp2 -Ec option -Ec generates deep copy code for each serializable type T declared in an interface header file for soapcpp2. The soapcpp2 -Ed option -Ed generates deep deletion code. To obtain more information about the code generated by soapcpp2 for the data types specified in an interface header file for soapcpp2, use soapcpp2 -r option -r to generate a soapReadme.

The serialization and deserialization rules is almost identical for these two different styles, except for the following:. The soapcpp2 tool uses SOAP 1. The soapcpp2-generated default SOAP 1.

This is used to match inbound xmlns XML namespace bindings that are then associated with the prefix in the table. This works by using the specified pattern in the third column, when it matches the namespace URI of the inbound XML request message of course. However, the use of SOAP 1. To make the XML namespace table available to the developer, the soapcpp2 tool generates a. To use SOAP 1. Alternatively, add the following line to your interface header file generated by wsdl2h for soapcpp Enumerations and bit masks are also supported, see Section Enumeration serialization.

Validation constraints can be added to validate the XSD type values as explained further below. A typedef in an interface header file for soapcpp2 declares a schema type name. The soapcpp2 tool interprets typedef declarations the same way as a regular C compiler interprets them. The built-in primitive and derived numerical XSD types are listed below together with their recommended typedef declarations.

Each URI scheme imposes specialized syntax rules for URIs in that scheme, including restrictions on the syntax of allowed fragment identifiers. The recommended type declaration is:. Represents Baseencoded arbitrary binary data. For using the xsd:base64Binary XSD type, the use of the base64Binary representation of a dynamic array is strongly recommended, see Section base64Binary serialization.

However, the type can also be declared as a string and the encoding will be string-based:. However, it is the responsibility of the application to make sure the string content is according to the Base64 Content-Transfer-Encoding defined in Section 6.

Better is to use the base64 serializer that serializes binary data as xsd:base64Binary :. For C, see Section Boolean enumeration serialization for C. The corresponding type declaration is:. Represents a date and time. However, note that calendar times before the year or after the year cannot be represented. Also strings can be used to store xsd:dateTime types:. Represents a date. The type declaration is:. Represents arbitrary precision decimal numbers. Represents a duration of time.

The number of seconds can include decimal digits to arbitrary precision. Represents arbitrary hex-encoded binary data. It has a lexical representation where each binary octet is encoded as a character tuple, consisting of two hexadecimal digits [a-fA-F] representing the octet code. For example, "0FB7" is a hex encoding for the bit integer binary representation is For using the xsd:hexBinary XSD type, the use of the hexBinary representation of a dynamic array is strongly recommended, see Section hexBinary serialization.

However, it is the responsibility of the application to make sure the string content is hex formatted. Better is to use the hex serializer that serializes binary data as xsd:hexBinary :. Corresponds to an unbounded integer. Another possibility is to use strings to represent unbounded integers and do the translation in the application itself. Corresponds to a bit integer in the range to Corresponds to a negative unbounded integer.

Corresponds to a non-negative unbounded integer. Corresponds to a non-positive unbounded integer. Another possibility is to use strings to represent unbounded integers and do the translation in code. Represents normalized character strings. Normalized character strings do not contain the carriage return xD , line feed xA nor tab x9 characters.

It is recommended to use strings to store xsd:normalizedString XSD types. Corresponds to a positive unbounded integer. Both types of regular and wide strings can be used at the same time, by using a typedef name with a trailing underscore as follows:.

Represents a time. The lexical representation for time is the left truncated lexical representation for dateTime: hh:mm:ss. Represents tokenized strings. Tokens are strings that do not contain the line feed xA nor tab x9 characters, that have no leading or trailing spaces x20 and that have no internal sequences of two or more spaces. It is recommended to use strings to store xsd:token XSD types.

Corresponds to a bit unsigned integer in the range 0 to For example, the following declaration in the interface header file for soapcpp2 permits us to use regular strings and wide strings while mapping these both to the XSD xsd:string type:. XSD schema types form a hierarchy of types, with xsd:anyType at the root.

A container or array of xsd:anyType may actually contain any mix of types, i. On the other hand the typedef declarations cannot be used to support polymorphic types. Note the use of the trailing underscores for the class names to distinguish the typedef type names from the class names. We can also add the xsd:base64Binary and xsd:hexBinary types that serialize raw binary data in the hierarchy as follows:.

See Sections base64Binary serialization and hexBinary serialization. Wrapper structs are supported as well, similar to wrapper classes. But they cannot be used to implement polymorphism.

Rather, the wrapper structs are used to represent a xsd:sequence of elements or to add attributes to primitive types as explained in Section How to declare XML attributes. The s and t variables are assigned the same string. When serialized, t refers to the content of s :. However, strings declared with different typedef names will never be considered multi-reference even when they point to the same string.

To disable multi-references in SOAP 1. The implementation of string deserialization permits mixed content. When XML contains mixed text and tags when a string is expected, the text with tags are collected into the deserialized string.

For example, suppose the getInfo service operation returns some detailed information. The service operation is declared as:. The proxy of the service is used by a client to request a piece of information and the service responds with:.

A new feature to specify format patterns was introduced in gSOAP 2. A format string can be used as a pattern for a typedef float or double in the interface header file for soapcpp2 to specify the representation in XML. The soapcpp2 tool also generates an XML schema with xsd:totalDigits and xsd:fractionDigits for this type:.

The soapcpp2 tool encodes the constants of enumeration-typed variables in symbolic form using the names of the constants when possible to comply to SOAP's enumeration encoding style. Consider for example the following enumeration of weekdays:. An XML namespace prefix can be specified as part of the enumeration-type identifier's name, with the usual namespace prefix conventions for identifiers.

If the value of an enumeration-typed variable has no corresponding named constant, the value is encoded as a signed integer literal. For example, the following declaration of a workday enumeration type lacks named constants for Saturday and Sunday:. If the constant 5 Saturday or 6 Sunday is assigned to a variable of the workday enumeration type, the variable will be encoded with the integer literals 5 and 6 , respectively.

The soapcpp2 tool generates soapStub. To avoid name clashes with enumeration constants, you can use the following convention with double underscores to add the enum name to the enum constants:. Instead, an enumeration type should be used to serialize true and false values as xsd:boolean XSD type values. The xsd:boolean XSD type is defined as an enumeration in C as:. Peculiar of the SOAP encoding boolean type is that it only defines the values 0 and 1 , while the XSD xsd:boolean type defines false and true as valid values.

A bitmask is an enumeration of power-of-two flags. This declares a regular enum but enumerates the enumeration constants as a series of powers of 2 starting with 1. This means that the enumeration constants can be bitwise or-ed with the operator to form a bitvector bitmask which is serialized in XML as a list of symbolic values.

Note that the use of the enum name as a parameter does not require the asterisk, only the definition does. Structs do not support inheritance when declared in an interface header file for soapcpp2. This makes serialization of structs is more efficient compared to classes. Serialization functions for structs are global functions. A class and struct instance is serialized as an XML element with attributes and sub-elements, which is represented in XML schema as a complexType.

The class name is the XML schema type name and the member variables of the class are the type's accessors. A class name is required to be unique and cannot have the same name as a struct , enum , or a service operation name specified in the interface header file for soapcpp2. Only single inheritance is supported by the soapcpp2 tool. Multiple inheritance is not supported because of the limitations of the XML schema extensibility.

If a constructor is present, there must also be a constructor declaration with an empty parameter list. To obtain more information about the code generated by soapcpp2 for a struct or class, use soapcpp2 -r option -r to generate a soapReadme.

Classes and structs may be declared volatile if you don't want soapcpp2 to generate the class definition, see Section Serialization "as is" of volatile data types for more details. Class templates are supported with only one template argument, see Section STL containers.

Member variables of a class can be serialized as XML attributes using the type qualifier, if the member is a primitive type or pointer to a primitive type. Arrays may be embedded within a class and a struct using a pointer member and size information, see Section Non-SOAP dynamic arrays.

Void pointers may be used in a class or a struct, but you have to add a type field so the engine can determine the type of object pointed to, see Section Void pointer serialization. If a derived class instance is used in place of a base class instance, then the serialized XML form carries a xsi:type attribute with the derived class type to distinguish it from the base class type:. The deserialization of a class instance allows any ordering of the accessors in the XML message.

However, if a base class member name is identical to a derived class member name, because the member is overloaded, the base class member name must precede the derived class member name in the XML message. A class declaration in the interface header file for soapcpp2 may include method declarations.

If constructors are not defined, then soapcpp2 generates constructors for the class to initialize the class with default values for member variables or the initialization values for member variables given in the class declaration. To obtain more information about the code generated by soapcpp2 for a class, use soapcpp2 -r option -r to generate a soapReadme.

Setter and getter methods are invoked at run time upon serialization and deserialization of class instances, respectively.

The use of setter and getter methods adds more flexibility to the serialization and deserialization process. A setter method is called by the serializer. You can use setter methods to update a class instance just before it is serialized. For example, you can use setter methods to update a class instance right before serialization. Setters are methods for "set to serialize" operations.

Getter methods are immediately invoked after deserialization of a class instance. You can use them to adjust the contents of class instances right after the instance was populated by the deserializer. The active soap context will be passed to the get and set methods. A setter method should prepare the contents of the class instance for serialization. A getter method should process the instance after deserialization. Suppose that the type and options members of the attachment should be set when the class is about to be serialized.

The get method is invoked after the base64 data has been processed. You can use it for post-processing purposes. Here is another example. It defines a primitive update type. Therefore, elements of this type contain xsd:dateType data. A get method is invoked immediately after the instance is populated by the deserializer. The method is not invoked when the element is an xsi:nil element or has a SOAP href or ref attribute referencing a value located elsewhere in the XML message or document.

Getter methods enable streaming XML operations. A getter method is invoked when the object is deserialized and the rest of the XML message has not been parsed yet. An example is shown below:. After decoding, the getter method is invoked, which can be used to check the id before the rest of the SOAP message is parsed. Because C does not support inheritance, a different approach is use for C code, see Section Polymorphism, derived types, and dynamic binding in C for details.

This shows that the Derived class instance kept its identity as it passed through the server. See Section Void pointer serialization for details. Instead, we add the derived type structs to the base structs as members that point to the derived type value when the base type is dynamically overridden by one of the derived types. In this way we can de serialize a base type struct as usual or one of the derived structs when the base type is overridden.

To serialize a derived type struct in place of the base struct, we set its corresponding member point to the derived struct value, which is serialized with the xsi:type attribute to indicate a derived type is used in XML. Deserialization of a derived type struct is done automatically when the xsi:type attribute is present.

This approach with additional members pointing to derived types was introduced with gSOAP 2. This method is fully automated for the wsdl2h tool to generate an interface header file for soapcpp2 with the type derivations in C.

Using this method with soapcpp2 alone using a manually-specified interface header file produces the specified type inheritance in the soapcpp2-generated WSDL and XML schema files as complexType extensions. The soapcpp2 tool warns if a derived type has multiple base types.

At most one base type for a derived type may be specified. This special member must be:. When multiple derived types are declared for a base type, all immediately derived struct types are added as transient pointer members to the base type. Indirectly derived types do not need to be added to the base type as members, but it is perfectly fine to do so.

To properly declare derived types, make sure to include all base type members in the derived type. See Void pointer serialization for details. Attributes are primitive XSD types, such as strings, enumerations, boolean, and numeric types.

To declare an XML attribute in a struct or class, the qualifier is used with the type of the attribute. The qualifier declares an XML attribute for the type , flag , and state members. Default values can be associated with any member that has a primitive type in a struct or class, as is illustrated in this example. The default values are used when the receiving message does not contain the corresponding values.

Because a service operation request and response message is essentially a struct, XML attributes can also be associated with method requests and responses. Attributes can also be attached to the dynamic arrays, binary types, and wrapper classes and structs of primitive types. An element or attribute with type QName Qualified Name contains a namespace prefix and a local name.

QName normalization by the deserializer is applied to convert the prefix in the inbound XML message to the corresponding prefix defined in the XML namespace table, which means that the QName string is always received in normalized form.

When the elt and att members are serialized, their string contents are just output. When the members are deserialized however, the deserializer converts the prefix in the parsed QName to the prefix defined in the namespace table that corresponds to the same namespace URI.

The selector stores run-time usage information about the union member that is activated. A union within a struct or class with a selector member represents xsd:choice XML schema component. Each union member name has a selector value defined by:. These selector values enumerate the union members. Since 2. While the gSOAP serializers are designed to be robust, failing to set the selector to a valid union member can lead to a crash of the serializer, because it will attempt to serialize an invalid union member.

The deserializer of a union type sets the selector value to the currently active union member that was deserialized. Otherwise a gSOAP error code is returned.

Disables MIME attachments, e. This function must be called first to initialize DIME attachment send operations receives are automatic. This function adds a new attachment to the list of attachments, where ptr and size refer to the block of memory that holds the attachment data except when DIME streaming callback handlers are used as described in Section The type string parameter is the MIME type of the data.

All parameter values are copied, except ptr. Callback function pointer. The id , type , and options arguments are the DIME id, type, and options, respectively.

The callback should return handle , or another pointer value which will be passed as a handle to fdimeread and fdimereadclose. The handle contains the value returned by the fdimereadopen callback. The buf argument is the buffer of length len into which a chunk of data should be stored.

The actual amount of data stored in the buffer may be less than len and this amount should be returned by the application. The fdimewriteclose callback is called after successfully transmitting the data or when an error occurred.

The content is streamed into an application data store through multiple fdimewrite calls from the gSOAP attachment receiver. The id , type , and options arguments are the DIME id, type, and options respectively. The callback should return a handle which is passed to the fdimewrite and fdimewriteclose callbacks. The size is unknown in advance because DIME attachments may be chunked.

The handle contains the value returned by the fdimewriteopen callback. The buf argument contains the data of length len. The callback should return a gSOAP error code e. The fdimewriteclose callback is called after successfully receiving the data or when an error occurred. The callback should return handle , or another pointer value which will be passed as a handle to fmimeread and fmimereadclose.

The handle contains the value returned by the fmimereadopen callback. The fmimewriteclose callback is called after successfully transmitting the data or when an error occurred. The content is streamed into an application data store through multiple fmimewrite calls from the gSOAP attachment receiver. Content decoding may have to be considered by the application based on this value.

The callback should return a non-NULL handle which is passed to the fmimewrite and fmimewriteclose callbacks. The handle contains the value returned by the fmimewriteopen callback. The fmimewriteclose callback is called after successfully receiving the data or when an error occurred. The presence of attachments must be explicitly checked using the function below.

Should be called after a client-side call e. Returns 1 true when attachments are present. If present, each attachment MUST be processed with the function below. Collectives on Stack Overflow. Learn more. Asked 6 years, 10 months ago. Active 3 years, 1 month ago. Viewed 3k times. After running: wsdl2h. I use gSoap 2. Why not run wsdl2h on all WSDLs together? Then use soapcpp2 option -j on the one. Always works like a charm. Alex RE. AlexRE An example of that, if added to the documentation, would be helpful — villapx.

Add a comment. Active Oldest Votes.