hi Adrian, Thanks a lot for your explanation.
>To reduce the cost of this change to our customers, I modified the >WSDL2Ws > tool such that the generated stubs would hide these changes, except where > nillable simple types were present - What you mean here is that: if a element is nillable in the WSDL only then the WSDL2Ws tool will generate a pointer as the return type and store the return value in a pointer? And if the element is not nillable then the WSDL2WS tool generate the return type as a value type and store it in a non-pointer type varialble? Adrian is my understanding correct or am I wrong? >where, of course, we need to expose > these changes out to the customers applications. You mean ...? the generated stubs etc ? is it ? >Similarly, the original generated stubs only took in XSD simple types > by-value, so I modified this to allow the use of pointers when handling > nillable simple types. Is this also in-line with my first explanation for return types...? Roshan On Wed, 2005-02-23 at 08:37 +0000, Adrian Dick wrote: > Hi, Roshan, > > In response to your questions below: > > Before making these changes, the API only allowed XSD simple types to be > returned by-value (with the obvious exception of string based types), but > if the element is "nil" it doesn't have a value, so the deserializer would > return 0 (or the equivalent for the given type), but this then confuses the > issue of "did I receive a nil or a 0?". Therefore, I modified the API to > return by-pointer, so a "nil" element would be returned as a NULL pointer. > > To reduce the cost of this change to our customers, I modified the WSDL2Ws > tool such that the generated stubs would hide these changes, except where > nillable simple types were present - where, of course, we need to expose > these changes out to the customers applications. > Similarly, the original generated stubs only took in XSD simple types > by-value, so I modified this to allow the use of pointers when handling > nillable simple types. This aspect of the problem required no change to the > external API, but until this modification was made it wasn't actually > possible to send "nil" for anything other than string based types, despite > the internal serialization logic being capable of supporting nillable. > > Regards, > Adrian > _______________________________________ > Adrian Dick ([EMAIL PROTECTED]) > > Roshan Weerasuriya <[EMAIL PROTECTED]> wrote on 23/02/2005 08:01:05: > > > hi Adrian, > > > > >If you have tests containing nillable simple types, you will need to > > >make > > >modifications (pass by pointer rather than pass by value), otherwise > > >everything will work without modification. > > > > Can you please explain this little bit? > > > > > I am about to commit the fix for AXISCPP-290 "nillable simple types". > > The > > > > > fix for this is particularly extensive, and required changes to the > > > > > external API, however, I have absorbed these changes into > thegenerated > > > > > stubs. > > > > It would be great if you can just put some simple explanation on what > > you have done.... Why did it required changes to external APIs .. > > > > Roshan > > > > > > On Mon, 2005-02-21 at 12:31 +0600, Samisa Abeysinghe wrote: > > > I should have said : > > > the generated code now compiles fine both for server and client. > > > Thanks, > > > Samisa... > > > > > > > > > On Mon, 21 Feb 2005 12:23:28 +0600, Samisa Abeysinghe > > > <[EMAIL PROTECTED]> wrote: > > > > Hi Adrian, > > > > There were several problems compiling the RPC style code both > for > > > > server side and client. > > > > I fixed the WSDL tool and the code not compiles fine both for > > > > server and client. > > > > > > > > Client also runs fine. But the server side fails for base64 and > > > > date types. > > > > I have created a seperate issue on this AXISCPP-459 > > > > Thanks, > > > > Samisa... > > > > > > > > On Fri, 18 Feb 2005 10:25:12 +0000, Adrian Dick <[EMAIL PROTECTED] > > ibm.com> wrote: > > > > > Hi Guys, > > > > > > > > > > I am about to commit the fix for AXISCPP-290 "nillable simple > > types". The > > > > > fix for this is particularly extensive, and required changes to the > > > > > external API, however, I have absorbed these changes into > thegenerated > > > > > stubs. > > > > > > > > > > If you have tests containing nillable simple types, you will > > need to make > > > > > modifications (pass by pointer rather than pass by value), > otherwise > > > > > everything will work without modification. > > > > > > > > > > I have successfully tested the existing client tests on AIX, Linux > and > > > > > Windows, and have confirmed that valid, compilable, skeleton > > are produced > > > > > for the server (but have not been able to run the server tests). > > > > > > > > > > Regards, > > > > > Adrian > > > > > _______________________________________ > > > > > Adrian Dick ([EMAIL PROTECTED]) > > > > > WebSphere MQ and ESB Development > > > > > Tel: +44-(0)-1962-819212 > > > > > Notes: Adrian Dick/UK/[EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > >
