Hi Bill, So briefly your suggestion is, For wsdl operations in the stub, axis2_stub_servicename_opname should be replaced with axis2_stub_op_servicename_opname. axis2_stub_servicename_opname_start should be replaced with axis2_stub_start_op_servicename_opname.
and for consistency non wsdl-operations in the stub, axis2_stub_servicename_create should be replaced with axis2_stub_create_servicename. The only issue against this suggestion is, there the namespace part of the operation is not prefixed. But we can just forget that, if this solves all the problems. Anyway I doubt whether we can provide the old functions with a user option, since it need to add some code to the java tool (code portions not specific to c codegeneration), But we can give a try. I will let devs know this discussion and ask their suggestions. Thanks Dimuthu On Nov 17, 2007 2:32 AM, Bill Mitchell <[EMAIL PROTECTED]> wrote: > > 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] > >
