[
https://issues.apache.org/jira/browse/CXF-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2474.
------------------------------
Resolution: Fixed
Fix Version/s: 2.2.5
Assignee: Daniel Kulp
I did provide the suggested fix, but one major note is that the StaxDatabinding
specifically states in it's javadoc that it doesn't work with the standard
interceptors. You should be using the StaxDatabinding feature thing that
removes those interceptors.
Either that or (preferrably for 2.2.5) change to the SourceDatabinding which
does work with better with them and provides some extra flexibility as well as
better testing (due to the JAX-WS providers using it). Additional features
and stuff will be added to the SourceDatabinding and probably not the
StaxDatabinding.
> DocLiteralInInterceptor.handleMessage(Message) does not handle use case where
> message part is an XMLStreamReader
> ----------------------------------------------------------------------------------------------------------------
>
> Key: CXF-2474
> URL: https://issues.apache.org/jira/browse/CXF-2474
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2.4, 2.2.5
> Reporter: Michael Allman
> Assignee: Daniel Kulp
> Fix For: 2.2.5
>
> Attachments: DocLiteralInInterceptor.patch
>
>
> The DocLiteralInInterceptor.handleMessage(Message) method breaks on the use
> case where the message part is an XMLStreamReader.
> The code seems to assume that line 188:
> o = dr.read(p, xmlReader);
> actually "reads" the message XML from xmlReader and advances to the next
> message part. Not so when dr is an XMLStreamDataReader. In that case, o is
> in fact xmlReader itself.
> We need to check in the while condition at line 195 that o != xmlReader (or
> come up with a more elegant solution). I'm attaching a patch that does that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
