axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimuthu Gamage" <dimut...@gmail.com>
Subject Re: WSDL2C create function conflicts with SOAP operation named create
Date Sat, 17 Nov 2007 02:03:55 GMT
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 <wtmitchell3@acm.org> 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 <wtmitchell3@acm.org> 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: axis-c-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-c-user-help@ws.apache.org
> >>
> >>
> >
> >
>
> --
> 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: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>

Mime
View raw message