Testing results : It seems that I was right: apache soap checks first if there is a xsi:type present ? If yes then checks if it can resolve it and after that it checks for the xsi:null attribute. From my viewpoint, this seems to me not to be the preffered order... but maibe they have a reason to do so. But 'til then I think it is a bug. :o(((
HOw I have discovered that : using the tag <name xsi:type="xsd:string" xsi:null="true" /> instead of simply using the <name xsi:null="true" /> For those who use ksoap as client: I have solved this by modifying the class SOAPWriter in order to check if attribute is null. If so, then does not write the attribute at all. It was already done this, but comented ( // ) Thanks again for helping me , dovle > Simple as this: > I use ksoap as client and apache soap as server. Send from apache soap a > struct with xsi:null="true" for some attribs and the apache soap sais that > cannot deserialize the attribute . with the following message: > > <faultstring>No mapping found for ':name' using encoding style > 'http://schemas.xmlsoap.org/soap/encoding/'.</faultstring> > > Now I think I might know why does it reacts this way: my tag where it fails > looks like this : > <name xsi:null="true" /> > As you can see, there is no xsi:type. And maibe (here I need your > confirmation because I haven't worked too much with apache soap) the apache > soap checks the type first and after that checks if it is a null object. > Might be an apache 'bug'. (haven't read all the specs about soap, but ...) > > I will try to check if this is the cause and if so I will inform you if so. > > Thanks for all, > dovle > > > I ran into a problem using Apache SOAP 2.2 within WSAD (WebSphere Studio > > Application Developer IDE). To solve it the Apache SOAP jar had to > > appear before WSAD's webcontainer.jar in the CLASSPATH. There was a > > method conflict that caused the null objects to deserialize to objects > > built with the default constructor. You may have a similar conflict in > > one of your jar files.
