Although our environment was different (we where using Axis2 v1.1 client to Axis2 v1.1 server with rampart 1.1) - we did have a similar issue with SOAP faults not being able to be processed properly. As a way arround (although I may not recommend it, we where locked into the version of Axis, and had to work around the issue - I'd recommend trying newer versions of Axis and Axiom coupled to it), we turned off Axis processing the exceptions (via "options.setExceptionToBeThrownOnSOAPFault(false);") , and processed the XML ourselves to avoid this problem - this may have been an issue within the version of axiom that we where using, and it may be worth investigating axiom version for your code. (We used SoapUI and TCPMon extensively to help double check the XML to and from services to resolve this as well)
>>> [EMAIL PROTECTED] 09/11/07 5:53 pm >>> Hi all!, We have some Web Services developed with asp.net 2.0. They work fine, and we haven't had problems with interoperatibility between platforms until now. A few days ago, a customer started to use our platform with an Axis2 client. We haven't experience giving support with Axis2. Until now, all the access to our platform had been with clients developed in .Net or Java with the XFire library. Both .Net and XFire use the SOAP 1.1 by default, although (at least in .Net) you can force the use of 1.2 version without problems. Axis2 use by default SOAP 1.2. All seemed to work fine until an exception was raised. In that moment, the Axis2 client launched an error: "org.apache.axiom.om.impl.exception.OMBuilderException: detail unsupported element in SOAPFault element" That is, it looks like if the Axis2 generated classes don't know how to read the "detail" element in the SOAPFault XML code generated by .Net. The "detail" element is part of the SOAPFault protocol, son we don't understand why is failing. With a .Net client all work fine. With a XFire too (in both cases, the tests have been done with SOAP 1.1 and SOAP 1.2). With Axis2, it only works fine if we force the client to use the SOAP 1.1 Protocol (options.setSoapVersionURI(Constants.URI_SOAP11_ENV)). Has anyone had a similar problem? We have another problem, this time with nulls. In .Net or XFire, if you don't send a data (for example, an integer field in a complex data type), is received at the server as "null" (element is marked as nilable = true in the WSDL). However, we are receiving a 0, and it causes a lot of problems. We have "resolved" the problem like this: Instead of this (is pseudocode): Client client = new Client(); client.name = "Jhon Doe"; client.Insert(); With Axis2, our clients have to do this (is pseudocode): Client client = new Client(); client.code = Integer.MIN_VALUE; client.name = "Jhon Doe"; client.Insert(); What is very extrange, and we don't understand the reason. Is there any way to change this behaviour? Thanks in advance! ***************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/ received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is strictly prohibited. The information contained in this email, including any attachment sent with it, may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone collect on Australia +61 1800 198 175 or by return email. You should also delete this email, and any copies, from your computer system network and destroy any hard copies produced. If not an intended recipient of this email, you must not copy, distribute or take any action(s) that relies on it; any form of disclosure, modification, distribution and/or publication of this email is also prohibited. Although Queensland Health takes all reasonable steps to ensure this email does not contain malicious software, Queensland Health does not accept responsibility for the consequences if any person's computer inadvertently suffers any disruption to services, loss of information, harm or is infected with a virus, other malicious computer programme or code that may occur as a consequence of receiving this email. Unless stated otherwise, this email represents only the views of the sender and not the views of the Queensland Government. ****************************************************************
