[
https://issues.apache.org/jira/browse/CXF-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766690#action_12766690
]
Daniel Kulp commented on CXF-2474:
----------------------------------
With 2.2.5, the SourceDatabinding properly supports either the Java6
javax.xml.transform.stax.StAXSource object or our own
org.apache.cxf.staxutils.StaxSource (subclass of SAXSource) which can hold onto
the XMLStreamReader.
In anycase, if you configure in a feature of class
org.apache.cxf.databinding.stax.StaxDataBindingFeature (see
http://cxf.apache.org/docs/features.html), it should remove the interceptors it
has problems with and put in a new one.
> 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.
