Huitang.. I also have the same problem you had. Please tell me what version of the axiom jar solved this issue.
Thanks in advance. / Yongseung Jeon. -----Original Message----- From: Huitang Li [mailto:[email protected]] Sent: Friday, July 17, 2009 12:08 PM To: [email protected] Subject: Re: server fault is not returned to the client when the client-side repository is used with addressing module It turns out that there is a simple solution there. Just replace apache axiom jars with the latest axiom jars, and it will solve the issue. It is caused by an apache axiom bug which affects rampart. NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. Nothing contained in this message or in any attachment shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. ----- Original Message ----- From: "Huitang Li" <[email protected]> To: [email protected] Sent: Thursday, July 16, 2009 6:55:03 PM GMT -06:00 US/Canada Central Subject: Re: server fault is not returned to the client when the client-side repository is used with addressing module In addition, I am using addressing module and rampart module for security on both client and server. >From some web postings, it seems that the "The input stream for an incoming >message is null" is caused by rampart. However, I cannot find a solution. I am >using rampart-1.4.mar Any help? Thanks. NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. Nothing contained in this message or in any attachment shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. ----- Original Message ----- From: "Huitang Li" <[email protected]> To: [email protected] Sent: Thursday, July 16, 2009 6:05:55 PM GMT -06:00 US/Canada Central Subject: server fault is not returned to the client when the client-side repository is used with addressing module Hi, I am using client-side repository with addressing module to connect to an Axis 2.1.4.1 web service(In-out pattern). The client and the web service are both running on my local machine. One thing I notice is that when a fault is thrown in the server, the client side got "500 Internal Server Error" in the response, and no fault message is received, and then client side throws an axis exception: org.apache.axis2.AxisFault: The input stream for an incoming message is null. at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:72). ........ Two things are noticed: 1) If there is no fault generated in the server, the client receives the expected soap response. 2) If the client side does not use addressing module in the client-side repository, the client will receive the server fault. The problem is: the client needs to use addressing module and needs to receive the fault when the fault is generated in the server. Does anyone know how to handle it? I tried to disable "chunk" as suggested by at least one posting for the "The input stream for an incoming message is null" issue, and it does not help solve my problem. Thanks very much. Thanks. NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. Nothing contained in this message or in any attachment shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions.
