Hi,
Thanks for the swift response. I noticed that the majority of existing tests
for the CXF component redirect from one CXF endpoint to another. That surely
works :). I am currently prototyping with Camel for a fairly complex
integration project, so I have to deal with routings that include diverse
components/processors. It appears that problems occur mainly when you put
something non-CXF in the middle, when message transformations take place.
Just FYI some results of my work with the component so far:
I had difficulty working with PAYLOAD and MESSAGE formats, when the actual
response is generated by XSLT or some "plain" processor (as opposed to
another CXF provider). By difficulty I mean some internal crashes with
runtime exceptions. It would be really helpful to see any samples how that
could be done.
For POJO dataFormat it turned out that the actual response should be wrapped
with a Object[]:
exchange.getOut().setBody(new Object[]{responseObject});
The same is true for the request parameter if accessed inside processor:
exchange.getIn().getBody() - returns an array for a method that takes a
single argument.
It would be nice if the following structure worked (at least for operations
that take a single argument):
exchange.getIn().getBody(RequestObject.class) // now naturally returns null
since the underlying structure is of a different type.
Thanks,
Mikhail
willem.jiang wrote:
>
> Hi,
>
> I just tried what you said, the test could pass , but when I call the
> Non-oneway method , I just got the message content which I just sent
> out. I will do some debug tomorrow.
>
> BTW, if you move the Processor from the camel context DSL and send the
> message to a CXF endpoint, you can call the one-way to two-way operation
> successfully.
>
> Willem.
>
> mikhail wrote:
>> Hi,
>>
>> I am using Camel 1.2.0 and I have a problem with the CXF component when
>> used
>> with one-way (void) operations.
>>
>> Basically I could not make the CXF component to work with one-way
>> operations
>> regardless of the message format (tried POJO, MESSAGE and PAYLOAD).
>>
>> The following simple router is producing the attached stacktrace (see at
>> the
>> bottom):
>>
>> from("cxf://${url}?dataFormat=POJO&inOut=false&${other.service.params}"())
>> .process(new Processor() {
>> public void process(Exchange exchange) {
>> System.out.println("Got here");
>> }
>> })
>> .to("mock:result");
>>
>> It looks like the immediate NPE might occur because of the following code
>> in
>> org.apache.camel.component.cxf.CXFMessage (I added my comments)
>>
>> public CxfMessage(Message cxfMessage) {
>> if (cxfMessage == null) {
>> this.cxfMessage = new MessageImpl();
>> }
>> //
>> // If the passed cxfMessage is null it is assigned to
>> this.cxfMessage here
>> // regardless of the above null check
>> // sounds like else {} is needed here
>> //
>> this.cxfMessage = cxfMessage;
>> }
>>
>> Regards,
>>
>>
>> Stacktrace:
>>
>>
>> java.lang.NullPointerException
>> at org.apache.camel.component.cxf.CxfBinding.getBody(CxfBinding.java:38)
>> at
>> org.apache.camel.component.cxf.CxfBinding.extractBodyFromCxf(CxfBinding.java:34)
>> at
>> org.apache.camel.component.cxf.CxfMessage.createBody(CxfMessage.java:93)
>> at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:41)
>> at org.apache.camel.impl.MessageSupport.copyFrom(MessageSupport.java:78)
>> at
>> org.apache.camel.impl.DefaultExchange.safeCopy(DefaultExchange.java:91)
>> at
>> org.apache.camel.impl.DefaultExchange.copyFrom(DefaultExchange.java:77)
>> at org.apache.camel.impl.DefaultExchange.copy(DefaultExchange.java:63)
>> at
>> org.apache.camel.processor.Pipeline.copyExchangeStrategy(Pipeline.java:180)
>> at
>> org.apache.camel.processor.Pipeline.createNextExchange(Pipeline.java:146)
>> at org.apache.camel.processor.Pipeline.process(Pipeline.java:84)
>> at
>> org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:40)
>> at
>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:44)
>> at
>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:68)
>> at
>> org.apache.camel.component.cxf.CamelInvoker.invoke(CamelInvoker.java:161)
>> at
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)
>> at
>> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>> at
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92)
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
>> at
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:268)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:224)
>> at
>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:54)
>> at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
>> at
>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
>> at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
>> at org.mortbay.jetty.Server.handle(Server.java:313)
>> at
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
>> at
>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
>> at
>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
>> at
>> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
>>
>
>
>
--
View this message in context:
http://www.nabble.com/CXF-Component-fails-with-one-way-operations-tf4774222s22882.html#a13661101
Sent from the Camel - Users mailing list archive at Nabble.com.
