camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From unmarshall <unmarsh...@gmail.com>
Subject Re: AW: AW: Calling external webservice using cxf camel endpoint
Date Tue, 02 Nov 2010 20:25:55 GMT

Hi Willem,

Thanks for your response. I always have trace on while development. For a
producer the binding operation info are never set. A look at the source code
for the producer confirms the same.

I added a custom processor which will then add the operation name and
namespace. It works if there is one external web service.

Now what is strange is that in case the route has 2 producers then CXF
applies transfer-encoding only to the request to the second external
webservice.

Following is the request that goes (you can see the
Transfer-Encoding=[chunked] there:

01:46:29.404 INFO  [default-workqueue-1] o.a.c.processor.interceptor.Tracer
[Logger.java:88] - ID-INLN50091056A-57098-1288728953488-11-5 >>> (route22)
com.sap.ping.util.OperationMappingProcessor@504a89f7 -->
cxf://bean:salesArrangementERPEndpoint <<< Pattern:InOut,
Headers:{User-Agent=Jakarta Commons-HttpClient/3.1, Host=localhost:8080,
SOAPAction="http://sap.com/xi/WebService/soap1.1",
operationName=salesArrangementERPByIdentifyingElementsQueryResponseIn,
accept-encoding=gzip,deflate,
ResponseContext={org.apache.cxf.interceptor.DocLiteralInInterceptor.DocLiteralInInterceptor.keep-parameters-wrapper=true,
javax.xml.ws.wsdl.port={http://sap.com/xi/APPL/SE/Global}SalesOrderItemByBuyerAndProductQueryResponseInImplPort,
org.apache.cxf.service.model.MessageInfo=[MessageInfo OUTPUT:
{http://sap.com/xi/APPL/SE/Global}salesOrderItemByBuyerAndProductQueryResponseInResponse],
org.apache.cxf.client=true, org.apache.cxf.message.inbound=true,
org.apache.cxf.message.Message.PROTOCOL_HEADERS={content-type=[text/xml;charset=utf-8],
Date=[Tue, 02 Nov 2010 20:16:29 GMT], transfer-encoding=[chunked],
Server=[Apache-Coyote/1.1]},
javax.xml.ws.wsdl.service={http://sap.com/xi/APPL/SE/Global}SalesOrderItemByBuyerAndProductQueryResponse_InService,
org.apache.cxf.message.Message.ENCODING=UTF-8,
javax.xml.ws.wsdl.interface={http://sap.com/xi/APPL/SE/Global}SalesOrderItemByBuyerAndProductQueryResponseInImpl,
javax.xml.ws.wsdl.operation={http://sap.com/xi/APPL/SE/Global}salesOrderItemByBuyerAndProductQueryResponseIn,
javax.xml.ws.wsdl.description=http://localhost:8081/jaxws-demows/SalesOrderItemByBuyerAndProductQuery?wsdl,
Content-Type=text/xml;charset=utf-8, org.apache.cxf.headers.Header.list=[],
org.apache.cxf.message.Message.RESPONSE_CODE=200},
org.apache.cxf.headers.Header.list=[], content-type=text/xml;charset=utf-8,
operationNamespace=http://sap.com/xi/APPL/SE/Global,
Server=Apache-Coyote/1.1, Date=Tue, 02 Nov 2010 20:16:29 GMT,
transfer-encoding=chunked}, BodyType:String, Body:<?xml version="1.0"
encoding="UTF-8"?>
<ns1:salesArrangementERPByIdentifyingElementsQueryResponseIn
xmlns:ns2="http://sap.com/xi/APPL/SE/Global"
xmlns:rootns="http://www.example.com/cmservices"
xmlns:ns1="http://sap.com/xi/APPL/SE/Global"
xmlns:ns0="http://www.example.com/cmservices">
<arg0>
<SalesArrangement>
<CustomerID/>
<SaleOrganisationalPartyInternalID/>
<DistributionChannelCode/>
<DivisionCode/>
</SalesArrangement>
<outputSize>10</outputSize>
</arg0>
</ns1:salesArrangementERPByIdentifyingElementsQueryResponseIn>

The problem is then even when i have the following configuration, it still
applies chunking:

	<http-conf:conduit name="*.http-conduit">
		<http-conf:client AllowChunking="false"/>
	</http-conf:conduit>

Which is strange in my opinion. I have the services hosted on tomcat. Now
when the chunked request goes to tomcat it throws an exception:

SEVERE: Couldn't create SOAP message due to exception: Unable to create StAX
reader or writer
com.sun.xml.ws.protocol.soap.MessageCreationException: Couldn't create SOAP
message due to exception: Unable to create StAX reader or writer
	at
com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:365)
	at
com.sun.xml.ws.transport.http.HttpAdapter.decodePacket(HttpAdapter.java:277)
	at
com.sun.xml.ws.transport.http.HttpAdapter.access$500(HttpAdapter.java:93)
	at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:457)
	at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
	at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
	at
com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
	at
com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
	at
com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
	at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
	at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
	at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:203)
	at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
	at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:108)
	at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:558)
	at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)
	at
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:281)
	at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:357)
	at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1671)
	at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
Caused by: com.sun.xml.ws.streaming.XMLReaderException: Unable to create
StAX reader or writer
	at
com.sun.xml.ws.api.streaming.XMLStreamReaderFactory$NoLock.doCreate(XMLStreamReaderFactory.java:412)
	at
com.sun.xml.ws.api.streaming.XMLStreamReaderFactory$Woodstox.doCreate(XMLStreamReaderFactory.java:436)
	at
com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.doCreate(XMLStreamReaderFactory.java:201)
	at
com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.create(XMLStreamReaderFactory.java:154)
	at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:301)
	at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:129)
	at
com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:360)
	... 25 more
Caused by: com.ctc.wstx.exc.WstxIOException: Invalid chunk header
	at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
	at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
	at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:660)
	at
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:355)
	at
com.sun.xml.ws.api.streaming.XMLStreamReaderFactory$NoLock.doCreate(XMLStreamReaderFactory.java:410)
	... 31 more
Caused by: java.io.IOException: Invalid chunk header
	at
org.apache.coyote.http11.filters.ChunkedInputFilter.doRead(ChunkedInputFilter.java:143)
	at
org.apache.coyote.http11.InternalAprInputBuffer.doRead(InternalAprInputBuffer.java:526)
	at org.apache.coyote.Request.doRead(Request.java:426)
	at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:286)
	at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:407)
	at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:309)
	at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:198)
	at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
	at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
	at java.io.InputStreamReader.read(InputStreamReader.java:167)
	at
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:245)
	at
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:132)
	at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:543)
	... 35 more

One of the possible reasons is listed @
http://trenaman.blogspot.com/2008/12/take-care-when-propagating-transport.html
- however setting AllowChunking="false" is not working for me. So i am stuck
yet again.

Any help would be appreciated.

Best Regards,
madhav


Willem.Jiang wrote:
> 
> On 10/27/10 9:36 PM, unmarshall wrote:
>>
>> Hi Christian,
>>
>> Thanks for your response. Camel Http component worked but that is not
>> what
>> we are looking for. Following are the reasons:
>>
>> 1. The routes are usually created by the clients and they range from
>> simple
>> to complex. Along with the routes they provide XSLT mappings which will
>> essentially only work on payloads. For using HTTP component i had to
>> change
>> the XSLT to add a soap envelop so that when a HTTP call is made to the
>> external webservice it does not fail because after application of XSLT on
>> the payload there is no soap envelop.
>> 2. If we use ServiceMix along with CXF we can easily do this by creating
>> cxf
>> consumers and producers so i am not sure why is this so difficult to do
>> using cxf and camel.
>>
>> I am planning to debug the Camel CXF codebase to see why
>> OperationBindingInfo is not found even when we explicitly set it on the
>> producer.
>>
> 
> Can you try to use the trace[1] to print out the messages ?
> Maybe the binding operation header is missing in the 4th endpoint.
> 
> You can add it back in a customer processor, if the header is missed.
> 
>> Thanks&  Regards,
>> Madhav
>>
>>
>> Schneider Christian wrote:
>>>
>>> Status code 500 means internal server error. I guess the endpoint you
>>> sent
>>> the request to was not able to process the request. Perhaps you will
>>> have
>>> more details in the log of this endpoint.
>>>
>>> It could be some invalid soap for that service...
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>> Christian Schneider
>>> Informationsverarbeitung
>>> Business Solutions
>>> Handel und Dispatching
>>>
>>> Tel : +49-(0)721-63-15482
>>>
>>> EnBW Systeme Infrastruktur Support GmbH
>>> Sitz der Gesellschaft: Karlsruhe
>>> Handelsregister: Amtsgericht Mannheim ­ HRB 108550
>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
>>> Geschäftsführer: Jochen Adenau, Hans-Günther Meier
>>>
>>>
>>
> 
> 
> -- 
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>           http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> 
> 

-- 
View this message in context: http://camel.465427.n5.nabble.com/Calling-external-webservice-using-cxf-camel-endpoint-tp3238383p3247439.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Mime
View raw message