Transfer-encoding chunked
Hi All, I'm having an issue calling a webservice on MS IIS from JBoss 4.2.2 with Apache CXF 2.0.4 client deployed in a Spring application. The deployed service doesn't seem to support client calls from JBoss with Transfer-encoding chunked in the request header. Sometimes the service system gives a response but most of the time it hangs or returns an error message. I've deployed exactly the same client code (generated with soapUI using CXF 2.0.4.-incubator) in a stand alone program in Eclipse. This program sends requests to the service with a content-length specified in the request header. This works perfectly well, the IIS server quickly responds and remains stable. So it appears to me that JBoss is actually responsible for putting the 'Transfer-encoding chunked' in the header. How can I reconfigure my JBoss to send requests with fixed content length. As a matter of fact, I think I should configure that only the web service requests have content-length specified. All other requests/responses should remain chunked. Or do I have to configure CXF or change my service client code to force the requests having a content-length header? I did some experiments with a cxf-servlet.xml in my WEB-INF without succes (ip address replaced with x's): http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"; xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd";> http://xx.xx.xx.xx/Webservice_Server/}Webservice_Server.http-conduit";> http://localhost:8080/axis2/services/}Version.http-conduit";> Any help is greatly appreciated! (Of course, the guys on the web service side should find out why their IIS becomes unstable, but i'd like to find out what i can change on the client side as well...) -- View this message in context: http://www.nabble.com/Transfer-encoding-chunked-tp16606556p16606556.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Transfer-encoding chunked
You seem to have done what I did[1, Step #8], but it is apparently not
working for you. Perhaps the "name" field of the http-conf:conduit is
incorrect and hence CXF is not picking up the command. Using
name="*.http-conduit" as shown near the top here[2] might fix your
problem.
HTH,
Glen
[1] http://www.jroller.com/gmazza/date/20070817
[2]
http://cwiki.apache.org/CXF20DOC/client-http-transport-including-ssl-support.html
Am Donnerstag, den 10.04.2008, 03:03 -0700 schrieb gbuys:
> Hi All,
>
> I'm having an issue calling a webservice on MS IIS from JBoss 4.2.2 with
> Apache CXF 2.0.4 client deployed in a Spring application.
>
> The deployed service doesn't seem to support client calls from JBoss with
> Transfer-encoding chunked in the request header. Sometimes the service
> system gives a response but most of the time it hangs or returns an error
> message. I've deployed exactly the same client code (generated with soapUI
> using CXF 2.0.4.-incubator) in a stand alone program in Eclipse. This
> program sends requests to the service with a content-length specified in the
> request header. This works perfectly well, the IIS server quickly responds
> and remains stable.
>
> So it appears to me that JBoss is actually responsible for putting the
> 'Transfer-encoding chunked' in the header. How can I reconfigure my JBoss
> to send requests with fixed content length. As a matter of fact, I think I
> should configure that only the web service requests have content-length
> specified. All other requests/responses should remain chunked.
>
> Or do I have to configure CXF or change my service client code to force the
> requests having a content-length header? I did some experiments with a
> cxf-servlet.xml in my WEB-INF without succes (ip address replaced with x's):
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:http-conf="http://cxf.apache.org/transports/http/configuration";
>
> xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
>http://cxf.apache.org/schemas/configuration/http-conf.xsd
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd";>
>
>
> name="{http://xx.xx.xx.xx/Webservice_Server/}Webservice_Server.http-conduit";>
>
>
>
>
> name="{http://localhost:8080/axis2/services/}Version.http-conduit";>
>
>
>
>
>
>
> Any help is greatly appreciated!
> (Of course, the guys on the web service side should find out why their IIS
> becomes unstable, but i'd like to find out what i can change on the client
> side as well...)
>
>
Re: Transfer-encoding chunked
OK, using wildcard "*.http-conduit" as the conduit name did the trick.
I still don't see why the specified name doesn't work though...
gbuys wrote:
>
> Hi All,
>
> I'm having an issue calling a webservice on MS IIS from JBoss 4.2.2 with
> Apache CXF 2.0.4 client deployed in a Spring application.
>
> The deployed service doesn't seem to support client calls from JBoss with
> Transfer-encoding chunked in the request header. Sometimes the service
> system gives a response but most of the time it hangs or returns an error
> message. I've deployed exactly the same client code (generated with
> soapUI using CXF 2.0.4.-incubator) in a stand alone program in Eclipse.
> This program sends requests to the service with a content-length specified
> in the request header. This works perfectly well, the IIS server quickly
> responds and remains stable.
>
> So it appears to me that JBoss is actually responsible for putting the
> 'Transfer-encoding chunked' in the header. How can I reconfigure my JBoss
> to send requests with fixed content length. As a matter of fact, I think
> I should configure that only the web service requests have content-length
> specified. All other requests/responses should remain chunked.
>
> Or do I have to configure CXF or change my service client code to force
> the requests having a content-length header? I did some experiments with
> a cxf.xml in my classpath without succes (ip address replaced with x's):
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xmlns:http-conf="http://cxf.apache.org/transports/http/configuration";
>
> xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
>http://cxf.apache.org/schemas/configuration/http-conf.xsd
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd";>
>
>
> name="{http://xx.xx.xx.xx/Webservice_Server/}Webservice_Server.http-conduit";>
>
>
>
>
> name="{http://localhost:8080/axis2/services/}Version.http-conduit";>
>
>
>
>
>
>
> Any help is greatly appreciated!
> (Of course, the guys on the web service side should find out why their IIS
> becomes unstable, but i'd like to find out what i can change on the client
> side as well...)
>
>
>
--
View this message in context:
http://www.nabble.com/Transfer-encoding-chunked-tp16606556p16608370.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Transfer-encoding chunked
If you have followed the instructions in the paragraph starting with
"The first thing to notice is..." on [1] closely in order to come up
with the exact name, and it still doesn't work, then possibly we have a
CXF bug. It can be tricky to get right.
Glen
[1]
http://cwiki.apache.org/CXF20DOC/client-http-transport-including-ssl-support.html
Am Donnerstag, den 10.04.2008, 05:32 -0700 schrieb gbuys:
> OK, using wildcard "*.http-conduit" as the conduit name did the trick.
>
> I still don't see why the specified name doesn't work though...
>
>
>
> gbuys wrote:
> >
> > Hi All,
> >
> > I'm having an issue calling a webservice on MS IIS from JBoss 4.2.2 with
> > Apache CXF 2.0.4 client deployed in a Spring application.
> >
> > The deployed service doesn't seem to support client calls from JBoss with
> > Transfer-encoding chunked in the request header. Sometimes the service
> > system gives a response but most of the time it hangs or returns an error
> > message. I've deployed exactly the same client code (generated with
> > soapUI using CXF 2.0.4.-incubator) in a stand alone program in Eclipse.
> > This program sends requests to the service with a content-length specified
> > in the request header. This works perfectly well, the IIS server quickly
> > responds and remains stable.
> >
> > So it appears to me that JBoss is actually responsible for putting the
> > 'Transfer-encoding chunked' in the header. How can I reconfigure my JBoss
> > to send requests with fixed content length. As a matter of fact, I think
> > I should configure that only the web service requests have content-length
> > specified. All other requests/responses should remain chunked.
> >
> > Or do I have to configure CXF or change my service client code to force
> > the requests having a content-length header? I did some experiments with
> > a cxf.xml in my classpath without succes (ip address replaced with x's):
> >
> > http://www.springframework.org/schema/beans";
> >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >
> > xmlns:http-conf="http://cxf.apache.org/transports/http/configuration";
> >
> > xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
> >http://cxf.apache.org/schemas/configuration/http-conf.xsd
> >http://www.springframework.org/schema/beans
> >http://www.springframework.org/schema/beans/spring-beans.xsd";>
> >
> >>
> > name="{http://xx.xx.xx.xx/Webservice_Server/}Webservice_Server.http-conduit";>
> >
> >
> >
> >>
> > name="{http://localhost:8080/axis2/services/}Version.http-conduit";>
> >
> >
> >
> >
> >
> >
> > Any help is greatly appreciated!
> > (Of course, the guys on the web service side should find out why their IIS
> > becomes unstable, but i'd like to find out what i can change on the client
> > side as well...)
> >
> >
> >
>
Re: Transfer-encoding chunked
Glen,
I tried several variations. Again, I've read the paragraph that you've
pointed to and tried out two possibilities:
1. Literally interpreted: the service's namespace= {Webservice_Server}. The
portname= Webservice_ServerSOAPPort
So we get: {Webservice_Server}Webservice_ServerSOAPPort.http-conduit
=> Not OK
2. Tried this:
{http://62.102.2.92/Webservice_Server}Webservice_ServerSOAPPort.http-conduit
=> Not OK
May be, I'm misinterpreting something (I'm rather new to web services)?
Didn't have the time to do some debugging.
Here's the wsdl fragment:
http://schemas.xmlsoap.org/wsdl/http/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:s0="Webservice_Server" xmlns="http://schemas.xmlsoap.org/wsdl/";
targetNamespace="Webservice_Server">
http://schemas.xmlsoap.org/soap/http";
style="document" />
http://xx.xxx.x.xx/Webservice_Server/Webservice_Server.soap"; />
Glen Mazza-2 wrote:
>
> If you have followed the instructions in the paragraph starting with
> "The first thing to notice is..." on [1] closely in order to come up
> with the exact name, and it still doesn't work, then possibly we have a
> CXF bug. It can be tricky to get right.
>
> Glen
>
> [1]
> http://cwiki.apache.org/CXF20DOC/client-http-transport-including-ssl-support.html
>
> Am Donnerstag, den 10.04.2008, 05:32 -0700 schrieb gbuys:
>> OK, using wildcard "*.http-conduit" as the conduit name did the trick.
>>
>> I still don't see why the specified name doesn't work though...
>>
>>
>>
>> gbuys wrote:
>> >
>> > Hi All,
>> >
>> > I'm having an issue calling a webservice on MS IIS from JBoss 4.2.2
>> with
>> > Apache CXF 2.0.4 client deployed in a Spring application.
>> >
>> > The deployed service doesn't seem to support client calls from JBoss
>> with
>> > Transfer-encoding chunked in the request header. Sometimes the service
>> > system gives a response but most of the time it hangs or returns an
>> error
>> > message. I've deployed exactly the same client code (generated with
>> > soapUI using CXF 2.0.4.-incubator) in a stand alone program in Eclipse.
>> > This program sends requests to the service with a content-length
>> specified
>> > in the request header. This works perfectly well, the IIS server
>> quickly
>> > responds and remains stable.
>> >
>> > So it appears to me that JBoss is actually responsible for putting the
>> > 'Transfer-encoding chunked' in the header. How can I reconfigure my
>> JBoss
>> > to send requests with fixed content length. As a matter of fact, I
>> think
>> > I should configure that only the web service requests have
>> content-length
>> > specified. All other requests/responses should remain chunked.
>> >
>> > Or do I have to configure CXF or change my service client code to force
>> > the requests having a content-length header? I did some experiments
>> with
>> > a cxf.xml in my classpath without succes (ip address replaced with
>> x's):
>> >
>> > http://www.springframework.org/schema/beans";
>> >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> >
>> > xmlns:http-conf="http://cxf.apache.org/transports/http/configuration";
>> >
>> > xsi:schemaLocation="http://cxf.apache.org/transports/http/configuratio
Re: Transfer-encoding chunked
Your (1) should be correct, but your declared target namespace:
"Webservice_Server" seems strange--shouldn't it start with http:// or
urn: or similar?
HTH,
Glen
Am Montag, den 14.04.2008, 00:34 -0700 schrieb gbuys:
> Glen,
>
> I tried several variations. Again, I've read the paragraph that you've
> pointed to and tried out two possibilities:
>
> 1. Literally interpreted: the service's namespace= {Webservice_Server}. The
> portname= Webservice_ServerSOAPPort
> So we get: {Webservice_Server}Webservice_ServerSOAPPort.http-conduit
> => Not OK
>
> 2. Tried this:
> {http://62.102.2.92/Webservice_Server}Webservice_ServerSOAPPort.http-conduit
> => Not OK
>
> May be, I'm misinterpreting something (I'm rather new to web services)?
> Didn't have the time to do some debugging.
>
>
> Here's the wsdl fragment:
>
>
> http://schemas.xmlsoap.org/wsdl/http/";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:s0="Webservice_Server" xmlns="http://schemas.xmlsoap.org/wsdl/";
> targetNamespace="Webservice_Server">
>
>
>
>
>type="s0:Webservice_ServerSOAPPortType">
>
> http://schemas.xmlsoap.org/soap/http";
> style="document" />
>
>soapAction="Webservice_Server/Query_Data_PerFir"
> style="document" />
>
>
>
>
>
>
>
>
>soapAction="Webservice_Server/Wissen_Werknemer"
> style="document" />
>
>
>
>
>
>
>
>
>
>soapAction="Webservice_Server/Check_Update_Werknemer"
> style="document" />
>
>
>
>
>
>
>
>
>soapAction="Webservice_Server/Query_Data_PerFir_1"
> style="document" />
>
>
>
>
>
>
>
>
>
>
>binding="s0:Webservice_ServerSOAPBinding">
>location="http://xx.xxx.x.xx/Webservice_Server/Webservice_Server.soap"; />
>
>
>
>
>
>
>
>
> Glen Mazza-2 wrote:
> >
> > If you have followed the instructions in the paragraph starting with
> > "The first thing to notice is..." on [1] closely in order to come up
> > with the exact name, and it still doesn't work, then possibly we have a
> > CXF bug. It can be tricky to get right.
> >
> > Glen
> >
> > [1]
> > http://cwiki.apache.org/CXF20DOC/client-http-transport-including-ssl-support.html
> >
> > Am Donnerstag, den 10.04.2008, 05:32 -0700 schrieb gbuys:
> >> OK, using wildcard "*.http-conduit" as the conduit name did the trick.
> >>
> >> I still don't see why the specified name doesn't work though...
> >>
> >>
> >>
> >> gbuys wrote:
> >> >
> >> > Hi All,
> >> >
> >> > I'm having an issue calling a webservice on MS IIS from JBoss 4.2.2
> >> with
> >> > Apache CXF 2.0.4 client deployed in a Spring application.
> >> >
> >> > The deployed service doesn't seem to support client calls from JBoss
> >> with
> >> > Transfer-encoding chunked in the request header. Sometimes the service
> >> > system gives a response but most of the time it hangs or returns an
> >> error
> >> > message. I've deployed exactly the same client code (generated with
> >> > soapUI using CXF 2.0.4.-incubator) in a stand alone program in Eclipse.
> >> > This program sends requests to the service with a content-length
> >> specified
> >> > in the request header. This works perfectly wel
