----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 13, 2002 7:41 AM Subject: RE: (Chained) Exceptions and beanMapping
Steve, >Sorry if my message sounded negative to you in any way. >I did not mean to do it. That's ok, I can recognise frustration when I see it. >However, JAX-RPC has specified that this WS method can generate Fault >events. The information of how it is handled by implementation is very >ambiguous. So, I think it is up to AXIS team to implement proper >handling if FAULTS. Am I wrong? Have just reread it and still dont understand fully, but it does seem like the spec says -exceptions should be serialized into the soap detail -the deserialize is very contrived, and doesnt use the normal bean model. I dont think axis does either of these yet, so a rework is in order >Particularly I want to achieve Fault processing/handling similar to >Complex type processing/handling. >AXIS has a way (in wsdd) to register (typeMapping) custom >serializer/deserializer for parameter. eys (snip) >Also, I noticed if web service method throws exception not derived from >AxisFault it DOES NOT serialize its fields (even if it follows JavaBean >spec). SHOULDN'T it be changed? yes, but the deserialize is still very different, and does not follow the javabean model. Why, I dont know, but it is there in the JAX-RPC spec. >What would you suggest in the situation like this? I don't want to end >up with RE-ENCODING all my Java exceptions into AXIS specific class >AxisFault - this would lock me into AXIS specific implementation. >Should be more elegant way of doing this... I dont know. I really have to sit down and understand soapfaults, jax-rpc and then look at axis, and do more experiments. One of the experiments is to throw javax.xml.rpc.soap.SOAPFaultException and see how axis deals with it. The other is to declare an exception in the WSDL and see what server side code is generated.
