[
https://issues.apache.org/jira/browse/CAMEL-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CAMEL-5877.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.10.4
Assignee: Daniel Kulp
I've done some heavy modifications to the patch and committed a fix. For the
most part, if the incoming object/message is in a form that we can directly
create a Source for it, I did that to avoid any of the "magic". For some
things (like xalan or Saxon) that may prefer a StreamSource, the may allow it
to remain as a StreamSource. If it's already a DOM, it can use a DOMSource as
well. Can you give that a look and see if that works better for your use case?
> Sporadic Source Conversion issues with CxfPayload
> -------------------------------------------------
>
> Key: CAMEL-5877
> URL: https://issues.apache.org/jira/browse/CAMEL-5877
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
> Affects Versions: 2.10.3
> Reporter: Aki Yoshida
> Assignee: Daniel Kulp
> Fix For: 2.10.4
>
> Attachments: camel-cxf-payload-source-20121214.patch
>
>
> There is one concrete issue to report and there is an additional point that I
> would like to bring up.
> First, the concrete issue is that CxfEndpoints' findName does not currently
> handle SAXSource. Consequently, the it fails to find the element name when
> the payload source is of SAXSource.
> This issue can be observed sporadically, as there is a chance the Source
> could be SAXSource. Because of the nature of this problem explained below,
> this issue may be observed non-deterministically and consequently it is not
> often observed.
> What is happening is that, when a conversion to CxfPayload is triggered,
> CxfPayloadConverter's convertTo method arbitrarily picks a converter that can
> convert the input to Source. The code goes into BaseTypeConverterRegistry and
> searches for a matching converter in its type mappings' entry set. As this
> set has no deterministic ordering and there are several matching converters,
> an arbitrary converter is picked up. THe chance of getting the SAXSource
> converter is small but not zero. Therefore, when this happens, CxfEndpoint's
> findName is not finding the element name as there is no handling for
> SAXSource. Interestingly, the DOMSource converter is the most frequently
> picked converter, followed by the StaxSource converter.
> So, SAXSource handling needs to be added in CXFEndpoint's findName method.
> The second point is about the preferred Source held in CxfPayload. I think
> for jdk 1.6 or above, StAXSource could be the preferred source. In that case,
> we can use the StAXSource converter instead of arbitrarily picking one of the
> Source converters. We can adjust CxfPayloadConverter's convertTo method to
> look up for the StAXSource converter first.
> I am attaching a proposed patch (the correction for the first issue and the
> suggestion regarding the second point, assuming StAXSource is preferred.).
> Could you review it and comment on it?
> Thanks.
> Regards, aki
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
