Ah, nice instructions. Will append a patch when I have something. Thanks.
>>> Freeman Fang <[email protected]> 11/9/2010 9:50 PM >>> Hi Kurt, As you're using 4.3.0-fuse-02-00, which use servicemix-cxf- bc-2010.02.0-fuse-01-00, so I suggest you should checkout the 010.02.0- fuse-01-00[1] release tag for servicemix-cxf-bc, and do some changes based on this version, then build a servicemix-cxf-bc-2010.02.0- fuse-01-00.jar from it and copy it to SMX4_HOME/system/org/apache/ servicemix/servicemix-cxf-bc/2010.02.0-fuse-01-00/servicemix-cxf- bc-2010.02.0-fuse-01-00.jar to override the old one to verify your fix. Don't build from apache side trunk as the 3 party jar dependency changes so you can't deploy it into 4.3.0-fuse-02-00 [1]https://fusesource.com/forge/svn/fuseesb/components/tags/components-pom-2010.02.0-fuse-01-00/bindings/servicemix-cxf-bc/ Freeman On 2010-11-10, at 上午10:30, Kurt Westerfeld wrote: > 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. > -- Freeman Fang ------------------------ FuseSource: http://fusesource.com blog: http://freemanfang.blogspot.com twitter: http://twitter.com/freemanfang Apache Servicemix:http://servicemix.apache.org Apache Cxf: http://cxf.apache.org Apache Karaf: http://karaf.apache.org Apache Felix: http://felix.apache.org
