Jiri Ondrusek created CAMEL-19837:
-------------------------------------
Summary: Converters - unpredictable behavior linked to type
hierarchy (flatpack)
Key: CAMEL-19837
URL: https://issues.apache.org/jira/browse/CAMEL-19837
Project: Camel
Issue Type: Bug
Components: core
Affects Versions: 4.x
Reporter: Jiri Ondrusek
Consequence of
[https://github.com/apache/camel/pull/11225/commits/e4007f2b1dfc982e5ea6a45427cbec8835ea58a5]
Camel-flatpack registers 2 converters:
# from net.sf.flatpack.DataSet to Map
# from net.sf.flatpack.Record to Map
Problematic case: If data for conversion is instance of
net.sf.flatpack.DefaultDataSet
Direct conversion is not possible (there is no DefaultDataSet -> Map converter)
therefore matching via interface is used (see
[https://github.com/apache/camel/blob/main/core/camel-api/src/main/java/org/apache/camel/converter/TypeConvertible.java#L101-L110)]
Problem is that `DefaultDataSet` implements `DataSet`, which extends `Record`.
Therefore based on the order of converters in the cache (map), "random"
converter is selected and used. Unfortunately one of these selection might
cause a problem.
I was trying to run test `fixedHeaderAndTrailerShouldSucceed` in camel-quarkus
from branch `camel-main`.
[code|https://github.com/apache/camel-quarkus/blob/camel-main/integration-tests/flatpack/src/test/java/org/apache/camel/quarkus/component/flatpack/it/FlatpackTest.java#L133]
# In case that converter `DataSet` -> `Map` is selected, the test
{*}succeeds{*}.
# If `Record` -> `Map` is selected, test {*}fails{*}.
I'd suggest to add a logic, which takes into consideration the fact, that some
of the matched interfaces are more general and some are more specific (in this
case, `DataSet` conversion should have higher priority).
There might be other approaches, but ^^ this one makes sense and should be
implementable (I'm not sure about possible performance affect)
(another way might be defining order of the converters, `DataSet` is always
tried before `Record` in Flatpack, performance should be better)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)