Hi devs, Following discussion is happening in the user mailing list regarding axis2/c codegen, Briefly the idea 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. This sounds little bit different from the naming convention followed so far, but it seems this solves most of the naming conflicts. Is there any better way we can do this, or is it ok to proceed with the above change, Any suggestions? Thanks Dimuthu ---------- Forwarded message ---------- From: Dimuthu Gamage <[EMAIL PROTECTED]> Date: Nov 17, 2007 7:33 AM Subject: Re: WSDL2C create function conflicts with SOAP operation named create To: Apache AXIS C User List <[EMAIL PROTECTED]> 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] > >
