WSDL2C Changes

[Milinda Pathirage <mi...@gmail.com>]

Hi,
While compiling the code generated for BaseDataTypesDocLitB service using
WSDL2C , I experienced with some compiling errors due some name conflicts
with axis2/c available data types and c built-in data types.  As a n example
consider there is a type called 'char' in our WSDL as in
BaseDataTypesDocLitB schema, then some part of generated code will look lie
this,

typedef axis2_char axis2_char_t;

struct axis2_char{
};

or
axis2_status_t AXIS2_CALL
axis2_char_free (axis2_char_t* char, const axutil_env_t *env)

These red bold things were the cause for compilation errors. Because of that
i propose to change the naming conventions of generated ADB code to
adb_<type_name>_t instead of axis2_ prefix. Also to avoid cases like second
example I propose we have to introduce '_' prefix to parameter name.
Then it will look like this:

typedef adb_char adb_char_t;

struct adb_char{
};

or
axis2_status_t AXIS2_CALL
adb_char_free (adb_char_t* _char, const axutil_env_t *env).

And we don't have implementations for all the XML Schema data types to do
data binding other than implementations for 'date time', 'duration', 'uri'
if I'm correct.

I think we have to really concentrate on WSDL2C tool and API of generated
code, because most of the threads in the user list are regarding code
generation.

Regards,
Milinda....

P. S Your suggestions will be greatly appreciated.




-- 
milindalakmal@cse.mrt.ac.lk
http://wsaxc.blogspot.com "Web services with Axis2/C"
http://www.milindalakmal.wordpress.com

Re: WSDL2C Changes

["Dr. Florian Steinborn" <fp...@gmx.de>]

> with the fix you are suggesting. But If the tool is buggy then it  
> effects the initial experience, thus the attitude.

+1 +1 +1

Flori

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org

Re: WSDL2C Changes

[Kaushalye Kapuruge <ka...@wso2.com>]

Hi Milinda,
Thanks for the effort.
Yes. Using axis2_ prefix as a great chance of making conflicts with 
existing types. So +1 for using a different prefix.
And using a prefix like"_" as I suggested earlier for parameter names is 
a MUST. In the Java implementation too they are using "_" prefix If I'm 
not mistaken.
Since many users start with the code generation it is inevitable that 
many threads are associated with the WSDL2C tool. This wouldn't change 
with the fix you are suggesting. But If the tool is buggy then it 
effects the initial experience, thus the attitude. I know that it's hard 
to support all most all WSDLs at this point :). But we should have some 
test cases little bit more complicated than we have now. Have a look at 
the WSDLs available here[1].
Cheers,
Kaushalye

[1]http://131.107.72.15/SoapWsdl%5FComplexDataTypes%5FXmlFormatter%5FService%5FIndigo/

Milinda Pathirage wrote:
> Hi,
> While compiling the code generated for BaseDataTypesDocLitB service 
> using WSDL2C , I experienced with some compiling errors due some name 
> conflicts with axis2/c available data types and c built-in data 
> types.  As a n example consider there is a type called 'char' in our 
> WSDL as in BaseDataTypesDocLitB schema, then some part of generated 
> code will look lie this,
>
> typedef axis2_char axis2_char_t;
>
> struct axis2_char{
> };
>
> or
> axis2_status_t AXIS2_CALL
> axis2_char_free (axis2_char_t* char , const axutil_env_t *env)
>
> These red bold things were the cause for compilation errors. Because 
> of that i propose to change the naming conventions of generated ADB 
> code to adb_<type_name>_t instead of axis2_ prefix. Also to avoid 
> cases like second example I propose we have to introduce '_' prefix to 
> parameter name.
> Then it will look like this:
>
> typedef adb_char adb_char_t ;
>
> struct adb_char{
> };
>
> or
> axis2_status_t AXIS2_CALL
> adb_char_free (adb_char_t* _ char, const axutil_env_t *env).
>
> And we don't have implementations for all the XML Schema data types to 
> do data binding other than implementations for 'date time', 
> 'duration', 'uri' if I'm correct.
>
> I think we have to really concentrate on WSDL2C tool and API of 
> generated code, because most of the threads in the user list are 
> regarding code generation.
>
> Regards,
> Milinda....
>
> P. S Your suggestions will be greatly appreciated.
>
>  
>
>
> -- 
> milindalakmal@cse.mrt.ac.lk <ma...@cse.mrt.ac.lk>
> http://wsaxc.blogspot.com "Web services with Axis2/C"
> http://www.milindalakmal.wordpress.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org

Re: WSDL2C Changes

["Dr. Florian Steinborn" <fp...@gmx.de>]

Hi Milinda,

I myself have not yet run into a problem like the one you described. Until  
now all the generated code was always compilable. But of course naming  
conflicts with c-reserved names should never occur.

> I think we have to really concentrate on WSDL2C tool and API of generated
> code, because most of the threads in the user list are regarding code
> generation.

I know it is not fair to say that. But: usually users just "use" a tool  
like WSDL2C and they expect everything will be all right with the  
generated code. And everytime it is not they write to the list.

BTW I hope that future releases of Axis2c will refrain from changing type  
names like it happened between 0.96 and 1.0. Given you would have  
developed extensively right from the start you would have found yourself  
in some trouble after "upgrading" to 1.0.

I really appreciate the work of your group! Keep on!

Greetings from Berlin,
Flori



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org