[jira] [Commented] (CAMEL-21513) CoreTypeRegistry can create unpredictable type to converter mappings

["Claus Ibsen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-21513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903008#comment-17903008 ] 

Claus Ibsen commented on CAMEL-21513:
-------------------------------------

You are welcome to work on a proposed path and send a PR or attach code to this JIRA

> CoreTypeRegistry can create unpredictable type to converter mappings
> --------------------------------------------------------------------
>
>                 Key: CAMEL-21513
>                 URL: https://issues.apache.org/jira/browse/CAMEL-21513
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 4.4.4
>            Reporter: Nathan
>            Priority: Minor
>
> *Context*
> The CoreTypeConverterRegistry uses a map of converters to find a converter for a TypeConvertible<from,to>.
> If there is no known converter it attempts to find one in the existing converter map based on the idea that an existing converter on a super class can be used.
> This logic is contained in the TypeResolverHelper.tryMatch method. The tryMatch method will do an exhaustive search on the types in the converter and the super classes of the to convert value.
> To do this tryMatch will iterate over all the existing converters. Each existing converter<from,to> will then be compared to the super classes of the TypeConvertible<from,to>.
> *Problem*
> The problem is that the TypeResolverHelper.tryMatch can be highly random in selecting a converter. The first converter that matches is chosen and stored for all future usage of this specific type conversion.
> But the order of iteration for the converter map is not guaranteed to be the same every time. It is very likely that it is different for every load, since it depends on the order that converters have been added and there is no order guarantee on HashMap entry set iteration.
> This is not only theoretical, we already had a problem with the type conversion of DeferredElementNSImpl to CxfPayload. DeferredElementNSImpl implements both org.w3c.dom.Element and org.w3c.dom.NodeList. Both of those have converters in the CxfPayloadConverterLoader.
> But the converter chosen was random and often changed after application restarts. This caused problems for us since the NodeList to CxfPayload did not transform the DeferredElementNSImpl as expected.
> *Workaround*
> There is an easy workaround by defining your own converters to ensure the correct conversion happens, but this workaround can be cumbersome for applications with a lot of implicit type conversions. 
> Especially if the correct conversion does exist, but is just not used.
> *Solution?*
> I do think there is a potential solution, the converter iteration is random and it would be inefficient to order it. That would also not necessarily fix anything since any order could be wrong for some specific conversion.
> Instead the TypeResolverHelper.tryMatch could change things by iterating over the super classes of the from first. And try to find a converter for each super class.
> The complication is that the super class iteration is done in the TypeConvertible, so it would have to be duplicated or moved into the TypeResolverHelper to do that.
> The method getInterfaces that is used in the TypeConvertible is ordered by the JDK, so there would be no randomness. Instead it would select the first existing converter that is actually closest to the target class.
> This is much better than just the first converter that happens to match with an interface removed 5 super classes.
> For the DeferredElementNSImpl it would then go:
> look for DeferredElementNSImpl -> not found
> look for ElementNSImpl -> not found
> look for ElementImpl -> not found
> Look for Element -> found CxfPayloadConverter.elementToCxfPayload



--
This message was sent by Atlassian Jira
(v8.20.10#820010)