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
