You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by NathanDM <nm...@comcast.net> on 2009/06/17 08:42:54 UTC
The input stream for an incoming message is null
I am consistently getting this message when trying to call a .Net server
endpoint from various generated clients. I've generated both jaxws bound
clients and adb clients. I've gotten them to find the right url and port.
But I keep getting:
"The input stream for an incoming message is null."
It is so consistent that I must have something subtle wrong in my setup - or
otherwise axis2 must be pretty useless. All the jars from Axis2 lib
directory are on the classpath.
The same error happens if I have a JAXWS server generated from a WSDL and a
client, generated from that same wsdl, trying to call that server.
Any ideas?
I'm really stuck, and need ideas for something to use besides axis2 if there
are no ideas.
--
View this message in context: http://www.nabble.com/The-input-stream-for-an-incoming-message-is-null-tp24067861p24067861.html
Sent from the Axis - User mailing list archive at Nabble.com.
Re: The input stream for an incoming message is null
Posted by NathanDM <nm...@comcast.net>.
Andreas Veithen-2 wrote:
>
> It's not a bug, it is called "chunked encoding". Obviously your server
> is not HTTP 1.1 compliant or refuses chunked encoding. There is an
> option in Axis2 to turn that off. By searching the documentation or
> the mailing list, you will be able to find some examples.
>
> Andreas
>
>
OK. So its a feature. ;) Although it is a pretty big gotcha. I had no idea
that ASP.NET development server didn't support chunked.
This works for turning chunked off in an ADB Client:
stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED,
"false");
despite previous archives that say it didn't work.
Anyone have ideas on how to turn it off for JAXWS clients?
Nathan
--
View this message in context: http://www.nabble.com/The-input-stream-for-an-incoming-message-is-null-tp24067861p24083424.html
Sent from the Axis - User mailing list archive at Nabble.com.
Re: The input stream for an incoming message is null
Posted by Andreas Veithen <an...@gmail.com>.
It's not a bug, it is called "chunked encoding". Obviously your server
is not HTTP 1.1 compliant or refuses chunked encoding. There is an
option in Axis2 to turn that off. By searching the documentation or
the mailing list, you will be able to find some examples.
Andreas
On Wed, Jun 17, 2009 at 21:23, NathanDM<nm...@comcast.net> wrote:
>
> Here is some interesting information from a tcp trace.
>
> Request:
>
> POST /WebService1.asmx HTTP/1.1
> Content-Type: text/xml; charset=UTF-8
> SOAPAction: "http://cgx.com/Test"
> User-Agent: Axis2
> Host: localhost:1401
> Transfer-Encoding: chunked
>
> c1
> <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><Test
> xmlns="http://cgx.com/"/></soapenv:Body></soapenv:Envelope>
> 0
>
> ======
> Response
>
> HTTP/1.1 400 Bad Request
> Server: ASP.NET Development Server/9.0.0.0
> Date: Wed, 17 Jun 2009 19:03:33 GMT
> X-AspNet-Version: 2.0.50727
> Cache-Control: private
> Content-Length: 0
> Connection: Close
> ===
>
> The headers seem mild enough. However where is the c1 at the beginning and
> the 0 at the end coming from?
>
> Another interesting data point.
>
> Trying to send some raw data through post - the same data minus the c1 and
> the 0. Look at the result:]
>
> Request:
> POST /WebService1.asmx HTTP/1.1
> Content-Type: text/xml; charset=UTF-8
> SOAPAction: "http://cgx.com/Test"
> User-Agent: Axis2
> Transfer-Encoding: chunked
> Host: localhost:1401
> Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
> Connection: keep-alive
> Content-Length: 193
>
> <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><Test
> xmlns="http://cgx.com/"/></soapenv:Body></soapenv:Envelope>
>
> ====================================
> Response:
>
> HTTP/1.1 200 OK
> Server: ASP.NET Development Server/9.0.0.0
> Date: Wed, 17 Jun 2009 19:06:27 GMT
> X-AspNet-Version: 2.0.50727
> Cache-Control: private, max-age=0
> Content-Type: text/xml; charset=utf-8
> Content-Length: 328
> Connection: Close
>
> <?xml version="1.0" encoding="utf-8"?><soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><TestResponse
> xmlns="http://cgx.com/"><TestResult>True</TestResult></TestResponse></soap:Body></soap:Envelope>
>
> =============================
>
> Definitely the request is more useful without the c1 and the 0. I had 1.4.1
> and upgraded to 1.5 and they probably both had this problem.
>
> Where are these extra characters coming from? I would be willing to pay
> twice as for a version of Axis that does not put those in there. ;)
>
> Nathan
>
> --
> View this message in context: http://www.nabble.com/The-input-stream-for-an-incoming-message-is-null-tp24067861p24080290.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
Re: The input stream for an incoming message is null
Posted by NathanDM <nm...@comcast.net>.
Here is some interesting information from a tcp trace.
Request:
POST /WebService1.asmx HTTP/1.1
Content-Type: text/xml; charset=UTF-8
SOAPAction: "http://cgx.com/Test"
User-Agent: Axis2
Host: localhost:1401
Transfer-Encoding: chunked
c1
<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><Test
xmlns="http://cgx.com/"/></soapenv:Body></soapenv:Envelope>
0
======
Response
HTTP/1.1 400 Bad Request
Server: ASP.NET Development Server/9.0.0.0
Date: Wed, 17 Jun 2009 19:03:33 GMT
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Length: 0
Connection: Close
===
The headers seem mild enough. However where is the c1 at the beginning and
the 0 at the end coming from?
Another interesting data point.
Trying to send some raw data through post - the same data minus the c1 and
the 0. Look at the result:]
Request:
POST /WebService1.asmx HTTP/1.1
Content-Type: text/xml; charset=UTF-8
SOAPAction: "http://cgx.com/Test"
User-Agent: Axis2
Transfer-Encoding: chunked
Host: localhost:1401
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 193
<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><Test
xmlns="http://cgx.com/"/></soapenv:Body></soapenv:Envelope>
====================================
Response:
HTTP/1.1 200 OK
Server: ASP.NET Development Server/9.0.0.0
Date: Wed, 17 Jun 2009 19:06:27 GMT
X-AspNet-Version: 2.0.50727
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 328
Connection: Close
<?xml version="1.0" encoding="utf-8"?><soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><TestResponse
xmlns="http://cgx.com/"><TestResult>True</TestResult></TestResponse></soap:Body></soap:Envelope>
=============================
Definitely the request is more useful without the c1 and the 0. I had 1.4.1
and upgraded to 1.5 and they probably both had this problem.
Where are these extra characters coming from? I would be willing to pay
twice as for a version of Axis that does not put those in there. ;)
Nathan
--
View this message in context: http://www.nabble.com/The-input-stream-for-an-incoming-message-is-null-tp24067861p24080290.html
Sent from the Axis - User mailing list archive at Nabble.com.
Re: The input stream for an incoming message is null
Posted by NathanDM <nm...@comcast.net>.
Deepal Jayasinghe-2 wrote:
>
> Are you tying to invoke one-way operation ? if so you need to use
> sendRobst or fireAndForget methods in the servcieclient. First check
> whether the service has a return value, you may check that using WSDL
> or by looking at the class.
>
> Thanks,
> Deepal
>
>
There is a method that takes no arguments and returns a string that I am
testing with. It is failing too. The other methods are void but .NET
generates a return value of XmlNode, and the client code generates response
classes anyway.
However, I am confused. I'm not sure whether calling "sendRobst or
fireAndForget methods in the serviceclient" are within my control when I am
using the generated proxy client code. Is the generated client code no
longer a supported path? It was still in the user guide.
I had a few other ideas. From the documentation, it is apparent that you
need all the jars on the classpath to run. Is there any configuration needed
or available when running client? The samples don't seem to use it.
I know there is an axis2.bat, but it doesn't seem to do anything for me
other than show the usage for the java command.
C:\InfDig\CGXIT\src\CJPConversionStatus\bin>"C:\Program
Files\Java\jdk1.6.0_13\bin\java" -Djava.ext.dirs="C:\Java\Axis2
-1.5\lib\" -Daxis2.repo="C:\Java\Axis2-1.5\repository"
-Daxis2.xml="C:\Java\Axis2-1.5\conf\axis2.xml" com.infdig.cjp.con
vert.test.TestAdbclients
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
The other idea is that some obscure security setting somewhere on my Windows
XP box. It is all localhost and port 8080 or 1438, but you never know.
--
View this message in context: http://www.nabble.com/The-input-stream-for-an-incoming-message-is-null-tp24067861p24077108.html
Sent from the Axis - User mailing list archive at Nabble.com.
Re: The input stream for an incoming message is null
Posted by Deepal Jayasinghe <de...@gmail.com>.
Are you tying to invoke one-way operation ? if so you need to use
sendRobst or fireAndForget methods in the servcieclient. First check
whether the service has a return value, you may check that using WSDL
or by looking at the class.
Thanks,
Deepal
On Wed, Jun 17, 2009 at 9:52 AM, NathanDM<nm...@comcast.net> wrote:
>
>
>
> Andrew Bruno wrote:
>>
>> Axis is NOT useless!
>>
>> Send us a stacktrace...
>>
>>
>>
>
> I couldn't seem to get one for the ADB client. This is the one for the JAXWS
> client. it is an AxisFault wrapped in a WebException.
>
> The input stream for an incoming message is null.
> [org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:87),
> org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67),
> org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354),
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:417),
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229),
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:165),
> org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:554),
> org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:118),
> org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:82),
> org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:317),
> org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:159),
> $Proxy12.test(Unknown Source),
> com.infdig.cjp.convert.test.TestCgx.TestSendToDotNet(TestCgx.java:90),
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method),
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39),
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25),
> java.lang.reflect.Method.invoke(Method.java:597),
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99),
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81),
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34),
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75),
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45),
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66),
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35),
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42),
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34),
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52),
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45),
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38),
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460),
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673),
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386),
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)]
>
> --
> View this message in context: http://www.nabble.com/The-input-stream-for-an-incoming-message-is-null-tp24067861p24074159.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
Re: The input stream for an incoming message is null
Posted by NathanDM <nm...@comcast.net>.
Andrew Bruno wrote:
>
> Axis is NOT useless!
>
> Send us a stacktrace...
>
>
>
I couldn't seem to get one for the ADB client. This is the one for the JAXWS
client. it is an AxisFault wrapped in a WebException.
The input stream for an incoming message is null.
[org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:87),
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67),
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354),
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:417),
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229),
org.apache.axis2.client.OperationClient.execute(OperationClient.java:165),
org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:554),
org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:118),
org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:82),
org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:317),
org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:159),
$Proxy12.test(Unknown Source),
com.infdig.cjp.convert.test.TestCgx.TestSendToDotNet(TestCgx.java:90),
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method),
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39),
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25),
java.lang.reflect.Method.invoke(Method.java:597),
org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99),
org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81),
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34),
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75),
org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45),
org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66),
org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35),
org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42),
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34),
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52),
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45),
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38),
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460),
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673),
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386),
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)]
--
View this message in context: http://www.nabble.com/The-input-stream-for-an-incoming-message-is-null-tp24067861p24074159.html
Sent from the Axis - User mailing list archive at Nabble.com.
Re: The input stream for an incoming message is null
Posted by Andrew Bruno <an...@gmail.com>.
Axis is NOT useless!
Send us a stacktrace...
On Wed, Jun 17, 2009 at 4:42 PM, NathanDM <nm...@comcast.net> wrote:
>
> I am consistently getting this message when trying to call a .Net server
> endpoint from various generated clients. I've generated both jaxws bound
> clients and adb clients. I've gotten them to find the right url and port.
> But I keep getting:
>
> "The input stream for an incoming message is null."
>
> It is so consistent that I must have something subtle wrong in my setup -
> or
> otherwise axis2 must be pretty useless. All the jars from Axis2 lib
> directory are on the classpath.
>
> The same error happens if I have a JAXWS server generated from a WSDL and a
> client, generated from that same wsdl, trying to call that server.
>
> Any ideas?
>
> I'm really stuck, and need ideas for something to use besides axis2 if
> there
> are no ideas.
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/The-input-stream-for-an-incoming-message-is-null-tp24067861p24067861.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>