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"/>
</operation>
...
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++.
Thanks,
Bill
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 <[EMAIL PROTECTED]> 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:
>> http://www.nabble.com/WSDL2C-create-function-conflicts-with-SOAP-operation-named-create-tf4818227.html#a13785056
>> Sent from the Axis - C++ - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/WSDL2C-create-function-conflicts-with-SOAP-operation-named-create-tf4818227.html#a13802853
Sent from the Axis - C++ - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
