I will attach a patch, but I need to test that it actually fixes the problem first. I'm little unclear on this code, whether it should return CxfJbiConstants.WSDL11_WRAPPER_PART_LOCALNAME or a blank prefix if the prefix is empty, but the namespace uri is null. (in other words, doesn't cause the wrong behavior when namespace is null?) Since I have the servicemix-cxf-bc sources from trunk, patching, building I know how to do. Do you have steps within the karaf console to undeploy the existing module and deploy my rebuilt one? I'm a little unclear on that part since it seems to be woven into the feature bundle, etc.
>>> "Freeman Fang (JIRA)" <[email protected]> 11/9/2010 12:38 PM >>> [ https://issues.apache.org/activemq/browse/SM-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63211#action_63211 ] Freeman Fang commented on SM-2009: ---------------------------------- Hi, Sorry I mismatch another fix in StaxJbiWrapper I saw this problem now. Thanks for pointing it out this issue. Btw, wanna append a patch to fix it? 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.
