You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2010/11/11 02:35:22 UTC

[jira] Moved: (SMXCOMP-821) servicemix-cxf-bc generates NPE, mapped to IOException, when marshaling messages that are document binding style in

     [ https://issues.apache.org/activemq/browse/SMXCOMP-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Freeman Fang moved SM-2009 to SMXCOMP-821:
------------------------------------------

          Component/s:     (was: servicemix-cxf-bc)
                       servicemix-cxf-bc
    Affects Version/s:     (was: archetypes-2010.02)
                       servicemix-cxf-bc-2010.01
                  Key: SMXCOMP-821  (was: SM-2009)
              Project: ServiceMix Components  (was: ServiceMix)

> servicemix-cxf-bc generates NPE, mapped to IOException, when marshaling messages that are document binding style in 
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: SMXCOMP-821
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-821
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2010.01
>         Environment: Using fuse 4.2 servicemix distribution
>            Reporter: Kurt Westerfeld
>            Assignee: Freeman Fang
>         Attachments: SM-2009.patch
>
>
> We are seeing an NPE within org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper, which marshals our message to the bus, during unmrashaling by servicemix-cxf-se.  
> The message content of our message is document based, but sub elements of message parameters are not ns-qualified (I believe this to be the problem).   This service implementation worked fine on servicemix 3 with prior releases of servicemix-cxf-bc, and we are in the process of porting to servicemix 4 with OSGi bundles.
> Here is the stacktrace for the code in question (this was grabbed by my debugger, but not propagated to the servicemix.log unfortunately):
> 	at org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.getPrefix(StaxJbiWrapper.java:251)
> 	at org.apache.servicemix.soap.util.stax.StaxSource.parse(StaxSource.java:110)
> 	at org.apache.servicemix.soap.util.stax.StaxSource.parse(StaxSource.java:227)
> 	at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:391)
> 	at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:366)
> 	at org.apache.cxf.transport.jbi.JBIMessageHelper.convertMessageToInputStream(JBIMessageHelper.java:41)
> 	at org.apache.cxf.transport.jbi.JBIDispatcherUtil.dispatch(JBIDispatcherUtil.java:149)
> 	at org.apache.servicemix.cxfse.CxfSeEndpoint.process(CxfSeEndpoint.java:460)
> 	at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:617)
> 	at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:571)
> 	at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx(AsyncBaseLifeCycle.java:468)
> 	at org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLifeCycle.java:347)
> 	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)
> The issue I see is that this method, "getPrefix()", is receiving a null back from parts.get(part).get(reader).getNamespaceURI(), which it turns around an tries to get the length on.  I stepped into the code here and found this to be the case.  Should be an easy fix.
> I created a workaround in my interceptor chain by fooling the servicemix-cxf-bc JbiInWsdl1Interceptor into creating a DOMSource instead of a StaxJbiWrapper, by temporarily setting the message state to "client" instead of "server" mode....ugly but it works.  This only works because the StaxJbiWrapper will throw UnsupportedOperationException back to the caller in this case.
> The NPE is being translated to an IOException as you can see below:
> java.io.IOException
> 	at org.apache.cxf.transport.jbi.JBIMessageHelper.convertMessageToInputStream(JBIMessageHelper.java:44)[155:org.apache.cxf.rt-transports-jbi:2.2.10.fuse-00-00]
> 	at org.apache.cxf.transport.jbi.JBIDispatcherUtil.dispatch(JBIDispatcherUtil.java:149)[155:org.apache.cxf.rt-transports-jbi:2.2.10.fuse-00-00]
> 	at org.apache.servicemix.cxfse.CxfSeEndpoint.process(CxfSeEndpoint.java:460)[156:servicemix-cxf-se:2010.02.0.fuse-01-00]
> 	at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:617)[90:servicemix-common:2010.02.0.fuse-01-00]
> 	at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:571)[90:servicemix-common:2010.02.0.fuse-01-00]
> 	at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx(AsyncBaseLifeCycle.java:468)[90:servicemix-common:2010.02.0.fuse-01-00]
> 	at org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLifeCycle.java:347)[90:servicemix-common:2010.02.0.fuse-01-00]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_18]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_18]
> 	at java.lang.Thread.run(Thread.java:619)[:1.6.0_18]
> Caused by: javax.xml.stream.XMLStreamException
> 	at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:394)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> 	at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:366)[138:org.apache.cxf.bundle:2.2.10.fuse-00-00]
> 	at org.apache.cxf.transport.jbi.JBIMessageHelper.convertMessageToInputStream(JBIMessageHelper.java:41)[155:org.apache.cxf.rt-transports-jbi:2.2.10.fuse-00-00]
> 	... 9 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.