axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yongseung Jeon" <fairw...@chol.com>
Subject RE: server fault is not returned to the client when the client-side repository is used with addressing module
Date Mon, 20 Jul 2009 09:10:36 GMT
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:hli@kpi-consulting.net] 
Sent: Friday, July 17, 2009 12:08 PM
To: axis-user@ws.apache.org
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" <hli@kpi-consulting.net>
To: axis-user@ws.apache.org
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" <hli@kpi-consulting.net>
To: axis-user@ws.apache.org
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.




Mime
View raw message