Roshan See responses below
Adrian _______________________________________ Adrian Dick ([EMAIL PROTECTED]) Roshan Weerasuriya <[EMAIL PROTECTED]> wrote on 23/02/2005 10:00:17: > 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? Correct. > > >where, of course, we need to expose > > these changes out to the customers applications. > You mean ...? the generated stubs etc ? is it ? Yes, for nillable these changes will be seen in the generated stubs. For non-nillable the generated stubs will appear as they always did. So, customer code using the generated stubs will only see a change if their WSDL has nillable simple types. > > >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...? Yes. > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
