OK, just one more question on this topic, and it's more of a process and procedures question. We're in the situation where we need to patch this component. We can fork a copy off the repo and build that, but what is the best way to distribute that? I would ideally like to create a "patch fragment" of sorts, but that seems to be a no-no. On the other hand, I don't care for purity of specs if it gets the job done. So, the options as I see it are: Fork and build our own copy (my least favorite option) Pull an updated build of the component from fusesource, if there is one, perhaps in SNAPSHOT form (is there?) Figure out how to do a patch fragment, perhaps tied to equinox or felix in some platform-specific way (which I like for our own reasons, because it might actually be something we want to do for our own components down the line). Hope this is an interesting question we can get a discussion on. I realize this might be a "Users" topic so please direct me that way if it is.
>>> "Freeman Fang (JIRA)" <[email protected]> 11/10/2010 8:47 PM >>> [ https://issues.apache.org/activemq/browse/SMXCOMP-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved SMXCOMP-821. ---------------------------------- Resolution: Fixed Fix Version/s: servicemix-cxf-bc-2010.02 apply patch on behalf of Kurt Westerfeld with thanks > StaxJbiWrapper throw NPE when use unqualified name for message part > ------------------------------------------------------------------- > > 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 > Fix For: servicemix-cxf-bc-2010.02 > > 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.
