You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by panzerhans <es...@tjonneland.no> on 2013/01/23 21:02:06 UTC

Websphere 6.1.0.45: Unable to return data from a camel-cxf component (POJO mode)

I have created a CXF webservice and exposed it with camel. The webservice is
code first (JSR-181) annotated Java class, springed up in my application
context.

The class looks like this:

@WebService(name="DataExport", serviceName="DataExport",
targetNamespace="com.somecompany.dataexport.v1")
public class DataExport {
    
    public String fetchVesselRegisterV1(@WebParam(name="input") SIInput
input) {
        return "";
    }
}

I understand that the return statement is never called as camel-cxf
intercepts the message on return (?). At least in a debugger it never stops
there.

My Spring config is like this:
 <cxf:cxfEndpoint id="export-webservice" address="/DataExport"
                    
serviceClass="com.somecompany.si.integration.data.export.DataExport">
        <cxf:properties>
            <entry key="dataFormat" value="POJO"/>
        </cxf:properties>
    </cxf:cxfEndpoint>

My Route is Java DSL with spring:
...
from("cxf:bean:export-webservice?dataFormat=POJO")//
                .routeId("DataExportWSRoute")//
               
.to("bean:com.somecompany.si.integration.data.export.ExportWSProcessor");
...

The handling bean correctly picks up the data when the webservice is called,
and I am able to read input parameters sent to the WS. However things go
wrong in Websphere after I push my reply (just a  Base64 encoded String)
into the exchange: exchng.getOut().setBody(encodedXML);

I get the following exception:

2013-01-23 20:33:35,585 WARN  WebContainer : 0        
|cxf.phase.PhaseInterceptorChain|logging.LogUtils-doLog() #369 [] -
Interceptor for
{com.somecompany.dataExport.v1}DataExport#{com.somecompany.dataExport.v1}fetchVesselRegisterV1
has thrown exception, unwinding now
java.lang.IllegalArgumentException: Invalid LF not followed by whitespace
	at
com.ibm.ws.genericbnf.impl.BNFHeadersImpl.checkHeaderValue(BNFHeadersImpl.java:4507)
	at
com.ibm.ws.genericbnf.impl.BNFHeadersImpl.appendHeader(BNFHeadersImpl.java:494)
	at
com.ibm.ws.webcontainer.channel.WCCResponseImpl.addHeader(WCCResponseImpl.java:209)
	at
com.ibm.ws.webcontainer.srt.SRTServletResponse.addField(SRTServletResponse.java:296)
	at
com.ibm.ws.webcontainer.srt.SRTServletResponse.addHeader(SRTServletResponse.java:1669)
	at
org.apache.cxf.transport.http.AbstractHTTPDestination.copyResponseHeaders(AbstractHTTPDestination.java:274)
	at
org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(AbstractHTTPDestination.java:557)
	at
org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(AbstractHTTPDestination.java:524)
	at
org.apache.cxf.transport.http.AbstractHTTPDestination$WrappedOutputStream.onFirstWrite(AbstractHTTPDestination.java:659)
	at
org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:42)
	at
com.ctc.wstx.sw.EncodingXmlWriter.flushBuffer(EncodingXmlWriter.java:698)
	at com.ctc.wstx.sw.EncodingXmlWriter.flush(EncodingXmlWriter.java:172)
	at com.ctc.wstx.sw.EncodingXmlWriter.close(EncodingXmlWriter.java:151)
	at
com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1429)
	at
com.ctc.wstx.sw.BaseStreamWriter.writeEndDocument(BaseStreamWriter.java:553)
	at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor.handleMessage(SoapOutInterceptor.java:282)
	at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor.handleMessage(SoapOutInterceptor.java:270)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
	at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:315)
	at
org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:77)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
	at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
	at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
	at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
	at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
	at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
	at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213)
	at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:658)
	at
com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:526)
	at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3673)
	at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:269)
	at
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:831)
	at
com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1478)
	at
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:133)
	at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:457)
	at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
	at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:300)
	at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:271)
	at
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
	at
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
	at
com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
	at
com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
	at
com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
	at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
	at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:196)
	at
com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:751)
	at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:881)
	at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1593)


*Note that when running the same code in Jetty, no problem is seen.*



--
View this message in context: http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Websphere 6.1.0.45: Unable to return data from a camel-cxf component (POJO mode)

Posted by panzerhans <es...@tjonneland.no>.
NB: Camel version: 2.6.0 (latest possible on Websphere 6.1).



--
View this message in context: http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083p5726084.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Websphere 6.1.0.45: Unable to return data from a camel-cxf component (POJO mode)

Posted by panzerhans <es...@tjonneland.no>.
Yes, I removed the header, and that works fine. 

However carrying all exchange headers over to HTTP headers makes it very
difficult to carry over "route payload" if the CXF endpoint was not the last
endpoint. However, I am getting the feeling it is not going to be easily
possible to respond back to the WS caller from the CXF bean, and continue
processing, e.g. storing something on a queue etc.





--
View this message in context: http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083p5726981.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Websphere 6.1.0.45: Unable to return data from a camel-cxf component (POJO mode)

Posted by Claus Ibsen <cl...@gmail.com>.
You can remove the unwanted headers.


On Tue, Feb 5, 2013 at 2:09 PM, panzerhans <es...@tjonneland.no> wrote:
> I've been able to work a bit more on this topic. Here is what is happening.
>
> The exchange headers used in the Camel part propagates into HTTP headers. I
> wasen't aware of this.
>
> Websphere is very strict about the content of the headers and a data object
> that I was using carried an illegal sequence inside its .toString method
> (illegal from Websphere HTTP header validation context).
> Jetty seems to ignore this.
>
> This leads to another question. Can I add headers to the
> "exchange.getOut.setHeader(......)" that can be prevented from propagating
> as HTTP headers with the SOAP communication?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083p5726967.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: Websphere 6.1.0.45: Unable to return data from a camel-cxf component (POJO mode)

Posted by panzerhans <es...@tjonneland.no>.
I've been able to work a bit more on this topic. Here is what is happening.

The exchange headers used in the Camel part propagates into HTTP headers. I
wasen't aware of this.

Websphere is very strict about the content of the headers and a data object
that I was using carried an illegal sequence inside its .toString method
(illegal from Websphere HTTP header validation context).
Jetty seems to ignore this.

This leads to another question. Can I add headers to the
"exchange.getOut.setHeader(......)" that can be prevented from propagating
as HTTP headers with the SOAP communication?



--
View this message in context: http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083p5726967.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Websphere 6.1.0.45: Unable to return data from a camel-cxf component (POJO mode)

Posted by panzerhans <es...@tjonneland.no>.
No change when wrapping the string inside an object.

I have two other contract first webservices. Those does not display the
above behaviour. So I am going to pick up the WSDL file and rewrite the
spring wiring.



--
View this message in context: http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083p5726183.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Websphere 6.1.0.45: Unable to return data from a camel-cxf component (POJO mode)

Posted by panzerhans <es...@tjonneland.no>.
Thank you for your reply.

For the WSDL: Yes, return type is correct.
<xs:complexType name="fetchVesselRegisterV1Response">
    <xs:sequence>
    <xs:element minOccurs="0" name="return" type="xs:string"/>
    </xs:sequence>
</xs:complexType>

I have tried both staying away from putting anything into the exchange.out
and instead manipulating the in body. This ended with a NPE:

2013-01-24 14:45:33,003 WARN  WebContainer : 0        
|cxf.phase.PhaseInterceptorChain|logging.LogUtils-doLog() #369 [] -
Interceptor for
{com.statoil.preemExport.v1}PreemExport#{com.statoil.preemExport.v1}fetchVesselRegisterV1
has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault
	at
org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:121)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
	at
org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:77)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
	at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
	at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
	at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
	at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
	at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
	at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213)
	at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:658)
	at
com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:526)
	at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3673)
	at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:269)
	at
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:831)
	at
com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1478)
	at
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:133)
	at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:457)
	at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
	at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:300)
	at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:271)
	at
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
	at
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
	at
com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
	at
com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
	at
com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
	at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
	at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:196)
	at
com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:751)
	at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:881)
	at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1593)
Caused by: java.lang.NullPointerException
	at
com.statoil.sis.integration.preem.export.jaxws_asm.FetchVesselRegisterV1Response_WrapperTypeHelper1.createWrapperObject(Unknown
Source)
	at
org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:105)
	... 34 more


After copying attachments and headers onto the Out (from In) and then again
setting the out body with the String same exception as before came. If I
change the return message to something simple like "Hello world" same
exception comes. 

I am going to try to wrap the response in a small object with getters and
setters to see if it makes a difference.




--
View this message in context: http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083p5726163.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Websphere 6.1.0.45: Unable to return data from a camel-cxf component (POJO mode)

Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jan 23, 2013 at 9:02 PM, panzerhans <es...@tjonneland.no> wrote:
> I have created a CXF webservice and exposed it with camel. The webservice is
> code first (JSR-181) annotated Java class, springed up in my application
> context.
>
> The class looks like this:
>
> @WebService(name="DataExport", serviceName="DataExport",
> targetNamespace="com.somecompany.dataexport.v1")
> public class DataExport {
>
>     public String fetchVesselRegisterV1(@WebParam(name="input") SIInput
> input) {
>         return "";
>     }
> }
>
> I understand that the return statement is never called as camel-cxf
> intercepts the message on return (?). At least in a debugger it never stops
> there.
>
> My Spring config is like this:
>  <cxf:cxfEndpoint id="export-webservice" address="/DataExport"
>
> serviceClass="com.somecompany.si.integration.data.export.DataExport">
>         <cxf:properties>
>             <entry key="dataFormat" value="POJO"/>
>         </cxf:properties>
>     </cxf:cxfEndpoint>
>
> My Route is Java DSL with spring:
> ...
> from("cxf:bean:export-webservice?dataFormat=POJO")//
>                 .routeId("DataExportWSRoute")//
>
> .to("bean:com.somecompany.si.integration.data.export.ExportWSProcessor");
> ...
>
> The handling bean correctly picks up the data when the webservice is called,
> and I am able to read input parameters sent to the WS. However things go
> wrong in Websphere after I push my reply (just a  Base64 encoded String)
> into the exchange: exchng.getOut().setBody(encodedXML);
>

You have configured CXF to use POJO mode.
So that means you must use the expected return type, from the web
service interface.
In your case its a String. So I guess its okay to return String data.

The generated .wsdl file does that indicate a return type of xs:string ?


And as you set response on getOut, then check this FAQ
http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html

Its possible easier to mutate the IN instead. Or else you may need to
propagate headers.
Though that's maybe not the cause here. Though a rule of thumb its
easier to mutate IN,
so you wont loose your headers etc during routing in Camel.

Could you log the base64 encoded data. It may cause the response XML
to be invalid etc.
Have you tried just to return "Hello World" or some plain text, to see
if that works?


> I get the following exception:
>
> 2013-01-23 20:33:35,585 WARN  WebContainer : 0
> |cxf.phase.PhaseInterceptorChain|logging.LogUtils-doLog() #369 [] -
> Interceptor for
> {com.somecompany.dataExport.v1}DataExport#{com.somecompany.dataExport.v1}fetchVesselRegisterV1
> has thrown exception, unwinding now
> java.lang.IllegalArgumentException: Invalid LF not followed by whitespace



>         at
> com.ibm.ws.genericbnf.impl.BNFHeadersImpl.checkHeaderValue(BNFHeadersImpl.java:4507)
>         at
> com.ibm.ws.genericbnf.impl.BNFHeadersImpl.appendHeader(BNFHeadersImpl.java:494)
>         at
> com.ibm.ws.webcontainer.channel.WCCResponseImpl.addHeader(WCCResponseImpl.java:209)
>         at
> com.ibm.ws.webcontainer.srt.SRTServletResponse.addField(SRTServletResponse.java:296)
>         at
> com.ibm.ws.webcontainer.srt.SRTServletResponse.addHeader(SRTServletResponse.java:1669)
>         at
> org.apache.cxf.transport.http.AbstractHTTPDestination.copyResponseHeaders(AbstractHTTPDestination.java:274)
>         at
> org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(AbstractHTTPDestination.java:557)
>         at
> org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(AbstractHTTPDestination.java:524)
>         at
> org.apache.cxf.transport.http.AbstractHTTPDestination$WrappedOutputStream.onFirstWrite(AbstractHTTPDestination.java:659)
>         at
> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:42)
>         at
> com.ctc.wstx.sw.EncodingXmlWriter.flushBuffer(EncodingXmlWriter.java:698)
>         at com.ctc.wstx.sw.EncodingXmlWriter.flush(EncodingXmlWriter.java:172)
>         at com.ctc.wstx.sw.EncodingXmlWriter.close(EncodingXmlWriter.java:151)
>         at
> com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1429)
>         at
> com.ctc.wstx.sw.BaseStreamWriter.writeEndDocument(BaseStreamWriter.java:553)
>         at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor.handleMessage(SoapOutInterceptor.java:282)
>         at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor.handleMessage(SoapOutInterceptor.java:270)
>         at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>         at
> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)
>         at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:315)
>         at
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:77)
>         at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
>         at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
>         at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
>         at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
>         at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
>         at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
>         at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
>         at
> com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213)
>         at
> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:658)
>         at
> com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:526)
>         at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3673)
>         at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:269)
>         at
> com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:831)
>         at
> com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1478)
>         at
> com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:133)
>         at
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:457)
>         at
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
>         at
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:300)
>         at
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:271)
>         at
> com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
>         at
> com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
>         at
> com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
>         at
> com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
>         at
> com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
>         at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
>         at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:196)
>         at
> com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:751)
>         at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:881)
>         at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1593)
>
>
> *Note that when running the same code in Jetty, no problem is seen.*
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Websphere-6-1-0-45-Unable-to-return-data-from-a-camel-cxf-component-POJO-mode-tp5726083.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen