users@grizzly.java.net

Re: TCP/HTTP Transfer-Encoding chunk problem

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Wed, 23 May 2007 11:01:52 -0400

Hi Yaman,

Ustuntas Yaman wrote:
> Hello,
>
> I am making a WSS security server with grizzly.

Are you using 1.0 or 1.5?

What the server returns
> seems fine if a url is requested by the client.
> But when I make a JAXWS call (generated stubs) to the service, the
> client fails with the following exception:
>
> javax.xml.ws.WebServiceException: Unsupported endpoint address:
> at
> com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:108)
> at
> com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:76)
> ....
>
> This client works fine if I call the same service deployed on
> tomcat/glassfish.
> I wrote another client, this time constructing the SOAP message manually
> with SOAPMessage class (+ security). This doesn't make the GET call
> before invoking the service and it works fine on my server.
> What JAXWS (generated stubs) does it to do a GET on the WSDL file first
> before invoking the service.
> The server returns the WSDL but there seems to be something wrong with
> the Transfer-Encoding chunk.

How are you staring the server (the command line)?


>
> I looked at the server output on the wire and the
> com.sun.grizzly.tcp.Response class doesn't seem send the "0\r\n" (to
> indicate the end of the chunks/response) in a seperate chunk but appends
> "0\r\n to the chunk containing the response.
> That is the only difference I could find which could make the JAXWS
> client fail.

The code is under tcp/http11/filters/ChunkedOutputFilter

I suspect that filter is not invoked properly. Is the header properl;y
chunked? If you can send me a test case, I can take a look.

Thanks!

-- Jeanfrancois

>
> Any suggestion on how I can make the "0\r\n" to be send in another
> (last) chunk?
>
>
> Thanks in advance :)
>
> --
> Yaman
>