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/09 17:51:00 UTC
[jira] Commented: (SM-2009) servicemix-cxf-bc generates NPE, mapped
to IOException, when marshaling messages that are document binding style in
[ https://issues.apache.org/activemq/browse/SM-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63205#action_63205 ]
Freeman Fang commented on SM-2009:
----------------------------------
Hi,
I believe this issue already get resolved.
The code you point to currently is
String prefix = parts.get(part).get(reader).getPrefix();
if (prefix != null && prefix.length() == 0
&& parts.get(part).get(reader).getNamespaceURI().length() > 0) {
return CxfJbiConstants.WSDL11_WRAPPER_PART_LOCALNAME;
} else {
return prefix;
}
Which already have null check first.
Could you use latest released apache-servicemix-4.3.0-fuse-02-00
Freeman
> servicemix-cxf-bc generates NPE, mapped to IOException, when marshaling messages that are document binding style in
> --------------------------------------------------------------------------------------------------------------------
>
> Key: SM-2009
> URL: https://issues.apache.org/activemq/browse/SM-2009
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-cxf-bc
> Affects Versions: archetypes-2010.02
> Environment: Using fuse 4.2 servicemix distribution
> Reporter: Kurt Westerfeld
> Assignee: Freeman Fang
>
> 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.