You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Beilin, Vadim" <Va...@morganstanley.com> on 2015/09/10 19:39:47 UTC
ReadHeadersInterceptor requires element prefix?
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.
Re: ReadHeadersInterceptor requires element prefix?
Posted by Aki Yoshida <el...@gmail.com>.
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 <as...@redhat.com>:
> 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:asoldano@redhat.com]
>> Sent: 10 September 2015 20:08
>> To: users@cxf.apache.org
>> 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
>
>
Re: ReadHeadersInterceptor requires element prefix?
Posted by Alessio Soldano <as...@redhat.com>.
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:asoldano@redhat.com]
> Sent: 10 September 2015 20:08
> To: users@cxf.apache.org
> 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
RE: ReadHeadersInterceptor requires element prefix?
Posted by "Beilin, Vadim" <Va...@morganstanley.com>.
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:asoldano@redhat.com]
Sent: 10 September 2015 20:08
To: users@cxf.apache.org
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.
Re: ReadHeadersInterceptor requires element prefix?
Posted by Alessio Soldano <as...@redhat.com>.
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