Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by SimonLegault: http://wiki.apache.org/ws/FrontPage/Axis/DotNetInterop ------------------------------------------------------------------------------ '''Q: But java.util.Calendar can take the value null, while .NET's System.Date''''''Time cannot. Isn't this a problem?''' - A: Yes. AXIS will serialize a null java.util.Calendar as something like <Date''''''Value xsi:nil='true'/>. De-serializing this XML into a System.Date''''''Time on the .NET side will result in an exception, since System.Date''''''Time can never be nil. There are some possible workarounds: + A: Yes. AXIS will serialize a null java.util.Calendar as something like <Date''''''Value xsi:nil='true'/>. De-serializing this XML into a System.Date''''''Time on the .NET side will result in an exception, since System.Date''''''Time can never be nil (not true with .NET 1.1.4322: .NET translates nil dateTime to .NET default DateTime, 0001-01-01T00:00:00). There are some possible workarounds: - a. select a particular date value to represent "no date at all", for example 1970/1/1. This requires strict enforcement on the Java side so that no nil value is every serialized to the wire. Also every Java app that uses a Calendar value obtained from a webservice must check the value of the Calendar against this well known "no value" value. + + a. select a particular date value to represent "no date at all", for example 1970/01/01 (or, even better, 0001-01-01). This requires strict enforcement on the Java side so that no nil value is every serialized to the wire (not needed if your .NET version is handling nil dateTime correctly). Also every Java app that uses a Calendar value obtained from a webservice must check the value of the Calendar against this well known "no value" value (this can be solved by adding a custom Axis deserializer that translates 0001-01-01T00:00:00 dateTime to null Calendar using a typeMapping configuration. TODO: add code and configuration sample). + - b. Wrap every date value in a wrapper type, that could take the null value. Again, this requires that any Java app that sends dates or times only sends them wrapped within such a structure. .NET Can de-serialize null wrapper types. One project that helps in this area is [http://nullabletypes.sourceforge.net/ the NullableTypes project] on SF.NET. + b. Wrap every date value in a wrapper type, that could take the null value. Again, this requires that any Java app that sends dates or times only sends them wrapped within such a structure. .NET Can de-serialize null wrapper types. One project that helps in this area is [http://nullabletypes.sourceforge.net/ the NullableTypes project] on SF.NET. + - c. Do special handling of nil Date''''''Time values on the .NET side, as per [http://cheeso.members.winisp.net/srcview.aspx?dir=xml-serialization&file=XsiNilDate.cs here] . + c. Do special handling of nil Date''''''Time values on the .NET side, as per [http://cheeso.members.winisp.net/srcview.aspx?dir=xml-serialization&file=XsiNilDate.cs here]. + d. Wait for .NET 2.0, which has support for Nullable'''''''Types built in. @@ -188, +192 @@ '''Q: Why sendNull parameter of the method "{{{org.apache.axis.encoding.SerializationContextImpl.serialize}}}" is hard code set to true ?''' - '''Remark: When you want to access to a Microsoft Web Services, the parameters with a Null value shouldn't be sent. I think it will be interesting to add a Tag in the {{{client-config.wsdd}}} to choose if we want to send {{{<Parameter xsi:nil="true"/>}}} in the SOAP envelope of the request.''' + '''Remark: When you want to access a Microsoft Web Services, the parameters with a Null value shouldn't be sent. I think it will be interesting to add a Tag in the {{{client-config.wsdd}}} to choose if we want to send {{{<Parameter xsi:nil="true"/>}}} in the SOAP envelope of the request.''' - -
