Thanks for your reply, Alessio. It turns out that one of the XMLStreamReader implementations involved was explicitly changing empty prefix to null to be in agreement with the Javadoc http://docs.oracle.com/javase/7/docs/api/javax/xml/stream/XMLStreamReader.html#getPrefix() as the authors of code understood it (and not only they, see eg https://bugs.openjdk.java.net/browse/JDK-6472960)
> It's kind of weird this was not reproduced by any test, though. As I said, the problem is due to our own library, but it's worth noting that grepping the CXF source tree for "<Envelope" brings back nothing. All the literal SOAP fragments used in the tests seem to be using non-empty prefixes. Thanks Vadim -----Original Message----- From: Alessio Soldano [mailto:[email protected]] Sent: 10 September 2015 20:08 To: [email protected] Subject: Re: ReadHeadersInterceptor requires element prefix? mmh... looks like a bug, introduced by CXF-5891 + CXF-6319 (a QName being constructed with prefix read from the stream and resulting null). It's kind of weird this was not reproduced by any test, though. Can you please create a jira and provide the dependency tree you reproduced this with, just in case ? I can most likely have a look in the next days. Cheers Alessio On 10/09/15 19:39, Beilin, Vadim wrote: > Hi, > We are moving one of our projects from CXF 2.7.12 to 2.7.16. > A number of tests are failing with exceptions like the following: > > java.lang.IllegalArgumentException: prefix cannot be "null" when creating a > QName > at javax.xml.namespace.QName.<init>(QName.java:251) > ~[na:1.7.0_67] > at > org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor$HeadersProcessor.process(ReadHeadersInterceptor.java:310) > ~[cxf-2.7.16.jar:2.7.16] > at > org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:190) > ~[cxf-2.7.16.jar:2.7.16] > at > org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:66) > ~[cxf-2.7.16.jar:2.7.16] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > ~[cxf-2.7.16.jar:2.7.16] > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > [cxf-2.7.16.jar:2.7.16] > > The message being sent looks like > <Envelope > xmlns="http://schemas.xmlsoap.org/soap/envelope/";><Body>..... > > It looks like ReadHeadersInterceptor.HeadersProcessor expects the elements > (Envelope, Header) to have a prefix. > I can't find any requirement to this effect (that the SOAP namespace should > not be a default namespace) in soap specs. > > Am I missing something here, or is it a regression in ReadHeadersInterceptor? > > Thanks > Vadim > > > ________________________________ > > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions > or views contained herein are not intended to be, and do not constitute, > advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform > and Consumer Protection Act. If you have received this communication in > error, please destroy all electronic and paper copies; do not disclose, use > or act upon the information; and notify the sender immediately. > Mistransmission is not intended to waive confidentiality or privilege. Morgan > Stanley reserves the right, to the extent permitted under applicable law, to > monitor electronic communications. This message is subject to terms available > at the following link: http://www.morganstanley.com/disclaimers If you cannot > access these links, please notify us by reply message and we will send the > contents to you. By messaging with Morgan Stanley you consent to the > foregoing. > -- Alessio Soldano Web Service Lead, JBoss -------------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.
