axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Mitchell <>
Subject Re: WSDL2C create function conflicts with SOAP operation named create
Date Fri, 16 Nov 2007 22:26:07 GMT

In a similar vein, although I could raise it as a separate issue, I have come
across another naming conflict in the output of the WSDL2C tool.  In the
same WSDL, I find another operation, this one named delete:
  <operation name="delete">
    <input message="fw:deleteRequest"/>
    <output message="fw:deleteResponse"/>

The template in the header for the stub for this operation is:
  axiom_node_t* axis2_stub_Fservice_delete( axis2_stub_t *stub, const
axutil_env_t *env,
                                                    axiom_node_t* delete);

The problem with this is that, although delete is not a reserved word in C,
it certainly is in C++.  And my goal is to invoke the Axis2C code from
within a C++ program.  So I would suggest that WSDL2C should prefix all of
the names generated as a result of the WSDL with something, and not leave
them naked where they could conflict with reserved words in C or C++.


Dimuthu Gamage wrote:
> Hi Bill,
> Yea, that is a big issue. But since the tool has been there for sometime
> there would be codes that stick to the current api given by the generated
> code..
> SO one thing we can do is, check whether the names for  operations
> conflicts
> with the _create, _populate_services and _get_endpoint_uri_from_wsdl, and
> if
> so we can prefix the operation names with some thing like "op"
> So your create operation would be,
> 'axis2_stub_FService_op_create'
> but all the other non-conflicting functions stays the same.
> Any ideas?
> Thanks
> Dimuthu
> On Nov 16, 2007 6:01 AM, Bill Mitchell <> wrote:
>> In order to communicate with a service written with another tool, I have
>> been
>> given a WSDL that includes a SOAP operation with the name "create":
>> ...
>> <portType name="IFService">
>>  <operation name="create">
>>    <input message="fw:createRequest"/>
>>    <output message="fw:createResponse"/>
>>  < /operation>
>> </portType>
>> ...
>> When I pass this WSDL through the WSDL2C utility, the generated header
>> file
>> constains two conflicting stubs with the same name.
>> The first is for its internal procedure to create a stub for the service:
>>    axis2_stub_t*
>>    axis2_stub_FService_create (const axutil_env_t *env,
>>                                        axis2_char_t *client_home,
>>                                        axis2_char_t *endpoint_uri);
>> The second is the procedure to invoke the create operation on the
>> service:
>>    axiom_node_t* axis2_stub_FService_create( axis2_stub_t *stub, const
>> axutil_env_t *env,
>>                                                    axiom_node_t* create);
>> Obviously, this doesn't work.  It would be nice were WSDL2C to add
>> something
>> more to the procedures that invoke the operations, such that the second
>> were
>> called axis2_stub_FService_invoke_create or
>> ..._FService_create_operation.
>> Is there some command line option I'm not seeing on WSDL2C that would
>> force
>> a more specific prefix on the operation stubs?
>> Of course, in a C++ world, the two functions could both exist as they
>> have
>> different signatures.  But I tried renaming and compiling the .c stub as
>> a
>> .cpp and that doesn't work.  The generated .c stub uses delete as a
>> parameter name.
>> The brute force way is to edit the stubs everytime they are generated to
>> solve the name conflict.  Were I in control of both sides, I could avoid
>> the
>> issue by changing the name of the operation from create to something
>> else.
>> --
>> View this message in context:
>> Sent from the Axis - C++ - User mailing list archive at
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

View this message in context:
Sent from the Axis - C++ - User mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message