Yes, Dimuthu, it occurred to me when I uncovered it that this is an issue without pretty solutions. Changing either the name of the axis support functions or the name of the generated operation functions would impact existing users who re-generated their stubs.
On the other hand, there are real problems with selective name changing when conflicts are detected. In this particular case, imagine that the generated name is changed from "create" to op_create" because "create" conflicts with the axis support function. Now the WSDL is changed to reflect a new function at the server, "op_create". When the stubs are regenerated, the create operation would conflict with the support function, and the first alternative name would conflict as well. So the code would fall to a second alternate? That would mean that for this user, WSDL2C generated stubs with one name, op_create, and now started generated stubs with a different name. This now inflicts on the one user with the conflict the abrupt change in names that we would like to avoid inflicting on all the users one time. The general problem with selective name changes is that they seemingly occur at random and will be a surprise to anyone who is not already experienced with Axis and has not seen them before. My recommendation would be to change the interfaces to include a string, e.g., _op_, in front of all the operation names. The only way to avoid the possibility of conflicts with names from the WSDL is for the string to be added to the front, and not to the end. As there is an existing problem with the names asynchronous operations, e.g., _create_start, the asynchronous start of a create operation, has the same name as _create_start, the synchronous invocation of a create_start operation, I suggest that these be changed at the same time. So the old axis2_stub_servicename_opname becomes axis2_stub_op_servicename_opname, and the old axis2_stub_servicename_opname_start becomes axis2_stub_start_op_servicename_opname. As you imply this is a longstanding issue, you may already be aware of other name conflicts that I have not yet uncovered that should be solved at the same time. Maybe, to make it a general practice and example everywhere, you would want to change all the generated names to have all the axis assigned names precede the servicename or other username, e.g., axis2_stub_servicename_create itself becomes axis2_stub_create_servicename. This might avoid future problems and give you more freedom to add new stub functions without creating new conflicts. Obviously, it would be nice to avoid the abrupt change under the existing user base, so the old naming convention would still need to be available through a command-line option or an option in a properties file. I would suggest the improved naming convention be the default so that new adopters of Axis2C don't encounter problems, as the goal should be to increase the number of adopters by making it as easy and trouble free as possible. Clearly the longer one waits to introduce such a change, the more existing users there are and thus the more users are inconvenienced by the change. It might have been nice to associate such a change with the introduction of Axis2, so that people might be more accepting of a radical change from the Axis1 behavior. 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#a13801351 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]
