In addition to what Alessio explained, I would also mention that the woodstox parser that CXF uses is not only spec-conformant but is also a very very good one from the performance and security point of view. In other words, using your own custom parser could be potentially inviting hackers to exploit some hidden weak spots in the implementation of that parser.
2015-09-11 14:04 GMT+02:00 Alessio Soldano <[email protected]>: > OK, this confirms my gut feeling you might be using a custom JAXP > implementation or such (that's why I asked for the dependency tree). > Given JDK-6472960 was rejected and we're in the START_ELEMENT/END_ELEMENT > scenario too, I'm leaning towards not fixing anything in CXF. Basically, the > interpretation to the javadoc is that null could be returned if there's *no* > prefix, as a consequence of the event not being a start/end element. > javax.xml.XMLConstants.DEFAULT_NS_PREFIX (which is the empty string) is used > to refer to default namespace prefix instead. > This said, if you want to submit a patch for that class that solves the > problem with your custom JAXP impl, I can verify it and possibly push it if > it's fine. > > As for the tests, it's not the CXF testsuite only being run; for instance, > CXF is included in WildFly and Red Hat JBoss EAP, which go through > additional testing including WS-I BP checks and full JavaEE certification > testing. > > Cheers > Alessio > > > On 11/09/15 12:52, Beilin, Vadim wrote: >> >> 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 > >
