You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Bill Mitchell <wt...@acm.org> on 2007/11/16 01:31:55 UTC
WSDL2C create function conflicts with SOAP operation named create
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
Re: WSDL2C create function conflicts with SOAP operation named create
Posted by Dimuthu Gamage <di...@gmail.com>.
Hi Bill,
Currently whenever there is a name conflict in schema elements, they will be
named with a post fix. And in the headers we should show the namespaces, so
the developers will be able to figure out the right element.
Thanks
Dimuthu
On Nov 21, 2007 8:16 AM, Bill Mitchell <wt...@acm.org> wrote:
>
> If I understand your reference to the absence of namespaces in my example,
> Dimuthu, you are correct to identify that as a distinct but similar name
> uniqueness issue. Certainly the WSDL itself could contain name conflicts
> that are resolved through the use of distinct namespaces. So, where I
> wrote
> "axis2_stub_start_op_servicename_opname", in the general case that would
> need to be "axis2_stub_start_op_ns1_servicename_ns2_opname". This could
> certainly be remedied as part of the same project. In the simple case
> where
> all the user names are part of the same namespace, one could default to
> the
> status quo and leave these out. To handle the general case, one could use
> the -N command line argument to WSDL2Java for the similar purpose here.
> This would allow the WSDL2C user to determine the prefix to be used for
> each
> namespace. The important part to avoid name conflicts, similar to the
> other
> situations I raised, is that every element always be generated or never
> generated. In a situation where namespace identifiers are included, they
> need to be included everywhere to guarantee that a namespace identifier in
> one place is not confused with the same string that is part of a user name
> in another place.
>
> And, of course, the other important part is the suggestion I made below,
> that all parts of the Axis generated name precede any parts of the user
> name, and no Axis string prefix be the leading substring of another Axis
> generated string prefix.
>
> I made my suggestion for an option to preserve the status quo only to
> handle
> the case where you folks think there is enough installed base and the
> change
> is awkward enough to demand it. I personally don't have a strong opinion
> one way or the other on compatibility with the status quo.
>
> Thanks,
> Bill
>
>
> 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
>
> --
> View this message in context:
> http://www.nabble.com/WSDL2C-create-function-conflicts-with-SOAP-operation-named-create-tf4818227.html#a13870069
> 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
>
>
Re: WSDL2C create function conflicts with SOAP operation named
create
Posted by Bill Mitchell <wt...@acm.org>.
If I understand your reference to the absence of namespaces in my example,
Dimuthu, you are correct to identify that as a distinct but similar name
uniqueness issue. Certainly the WSDL itself could contain name conflicts
that are resolved through the use of distinct namespaces. So, where I wrote
"axis2_stub_start_op_servicename_opname", in the general case that would
need to be "axis2_stub_start_op_ns1_servicename_ns2_opname". This could
certainly be remedied as part of the same project. In the simple case where
all the user names are part of the same namespace, one could default to the
status quo and leave these out. To handle the general case, one could use
the -N command line argument to WSDL2Java for the similar purpose here.
This would allow the WSDL2C user to determine the prefix to be used for each
namespace. The important part to avoid name conflicts, similar to the other
situations I raised, is that every element always be generated or never
generated. In a situation where namespace identifiers are included, they
need to be included everywhere to guarantee that a namespace identifier in
one place is not confused with the same string that is part of a user name
in another place.
And, of course, the other important part is the suggestion I made below,
that all parts of the Axis generated name precede any parts of the user
name, and no Axis string prefix be the leading substring of another Axis
generated string prefix.
I made my suggestion for an option to preserve the status quo only to handle
the case where you folks think there is enough installed base and the change
is awkward enough to demand it. I personally don't have a strong opinion
one way or the other on compatibility with the status quo.
Thanks,
Bill
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
--
View this message in context: http://www.nabble.com/WSDL2C-create-function-conflicts-with-SOAP-operation-named-create-tf4818227.html#a13870069
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
Re: Fwd: WSDL2C create function conflicts with SOAP operation named
create
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Dimuthu Gamage wrote:
> 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.
Makes sense. +1 for the change.
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Fwd: WSDL2C create function conflicts with SOAP operation named create
Posted by Dimuthu Gamage <di...@gmail.com>.
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 <di...@gmail.com>
Date: Nov 17, 2007 7:33 AM
Subject: Re: WSDL2C create function conflicts with SOAP operation named
create
To: Apache AXIS C User List <ax...@ws.apache.org>
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 <wt...@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
>
>
Re: WSDL2C create function conflicts with SOAP operation named create
Posted by Dimuthu Gamage <di...@gmail.com>.
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 <wt...@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 <wt...@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
>
>
Re: WSDL2C create function conflicts with SOAP operation named
create
Posted by Bill Mitchell <wt...@acm.org>.
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 <wt...@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
Re: WSDL2C create function conflicts with SOAP operation named create
Posted by Dimuthu Gamage <di...@gmail.com>.
Hi Bill,
Currently It tries to avoid following c reserved words,
"auto", "double", "int", "struct",
"break", "else", "long", "switch",
"case", "enum", "register", "typedef",
"char", "extern", "return", "union",
"const", "float", "short", "unsigned",
"continue", "for", "signed", "void",
"default", "goto", "sizeof", "volatile",
"do", "if", "static", "while"
Anyway It seems currently this doesn't affect on the operation parameters,
Can you please raise a JIRA on this issue.
Thanks
Dimuthu
On Nov 20, 2007 12:41 AM, Bill Mitchell <wt...@acm.org> wrote:
>
> Interesting suggestion, Samisa. I modified my WSDL renaming the "delete"
> operation to "struct" and used the WSDL2C utility to generate the stub and
> header files. I see the same result, the header contains a template with
> the dummy parameter name struct:
> axiom2_node_t* axis2_stub_TestService_struct( axis2_stub_t *stub, const
> axutil_env_t *env,
> axiom_node_t* struct);
> So, if there is a table that is used to filter C reserved words, that
> table
> is not being applied to the dummy parameter names when the operation stubs
> are generated.
>
>
> Bill Mitchell wrote:
> > 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++.
> >
>
> +1. I think we already track for C keywords. May be we can add C++
> keywords to that table as well.
>
>
> Samisa...
> --
> View this message in context:
> http://www.nabble.com/WSDL2C-create-function-conflicts-with-SOAP-operation-named-create-tf4818227.html#a13842836
> 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
>
>
Re: WSDL2C create function conflicts with SOAP operation named
create
Posted by Bill Mitchell <wt...@acm.org>.
Interesting suggestion, Samisa. I modified my WSDL renaming the "delete"
operation to "struct" and used the WSDL2C utility to generate the stub and
header files. I see the same result, the header contains a template with
the dummy parameter name struct:
axiom2_node_t* axis2_stub_TestService_struct( axis2_stub_t *stub, const
axutil_env_t *env,
axiom_node_t* struct);
So, if there is a table that is used to filter C reserved words, that table
is not being applied to the dummy parameter names when the operation stubs
are generated.
Bill Mitchell wrote:
> 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++.
>
+1. I think we already track for C keywords. May be we can add C++
keywords to that table as well.
Samisa...
--
View this message in context: http://www.nabble.com/WSDL2C-create-function-conflicts-with-SOAP-operation-named-create-tf4818227.html#a13842836
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
Re: WSDL2C create function conflicts with SOAP operation named create
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Bill Mitchell wrote:
> 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++.
>
+1. I think we already track for C keywords. May be we can add C++
keywords to that table as well.
Samisa...
> 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 <wt...@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
>>>
>>>
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: WSDL2C create function conflicts with SOAP operation named
create
Posted by Bill Mitchell <wt...@acm.org>.
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 <wt...@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#a13802853
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
Re: WSDL2C create function conflicts with SOAP operation named create
Posted by Dimuthu Gamage <di...@gmail.com>.
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 <wt...@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
>
>