The company I work for is in the process of doing an axis web service integration a with a client using the .NET framework 1.1 and Visual Studio 2003. Recently the client reported the following exception when making a request:
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, XmlDeserializationEvents events) at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader) at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClient Message message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at UnitTests.com.materialogic.www.CopperLinkV1.getItem(String sessionId, String id) in c:\ccviews\shipcompliant_robbd\shipcompliant1\sco_biz\sco_unittests\web references\com.materialogic.www\reference.cs:line 746 at UnitTests.CopperPeakWSIntegration.CopperPeakWSTests.Service_getItemIdList_ge tItem() in c:\ccviews\shipcompliant_robbd\shipcompliant1\sco_biz\sco_unittests\copperpe akwstests.cs:line 179 --InvalidOperationException at System.Number.ParseDecimal(String s, NumberStyles style, NumberFormatInfo info) at System.Decimal.Parse(String s, NumberStyles style, IFormatProvider provider) at System.Xml.XmlConvert.ToDecimal(String s) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read53 _Item(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read19 3_getItemResponse() The client believes this is a result of us returning a null for an expected decimal value, which is entirely possible. Most of the responses from our service will return null values for attributes that exist as such in our database. Doing an extensive search of the web, I seem to be finding the same answer over and over to this problem - the version of .NET that my client is using does not support null primitive types. Additionally, I see that it is recommended (for maximum interoperability) that we use java's primitive types in our responses (as a general practice we use java's primitive wrappers), thus making it necessary for us to assign a default value to all data in our responses. The problem with all of this is that true null values exist throughout our codebase and our database, and for the sanctity of our data we would prefer to not have to assign arbitrary fake-null values to data in our response, because this opens up the possibility of the client then returning this data to our system and then next thing you know we've got a bunch of "-1" values in our database for fields that are typically null. Has anyone out there experienced a similar situation? If so, how did you solve the problem? Thanks... Ben Paulsen
